Ais Manuscript Chapter 15
Ais Manuscript Chapter 15
By:
Abuda, Angelica
Diaz, Shally Mir
Sambayon, Sheena Mariz
Dela Peṅa, Christian Eve
BSBA-2A
CHAPTER 15:
THE SYSTEMS DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT:
ADDRESSING THE CHALLENGES OF BUILDING AIS SYSTEMS
LEARNING OBJECTIVES
• LO#1: Describe each phase in the systems development life cycle.
• LO#2: Explain the core principles of information systems planning
• LO#3: Define project management and describe the positions of those who lead the project.
• LO#4: Explain why IT projects are challenged and the tools that are used to overcome these
challenges.
• LO#5: Explain why users do or do not want to use a new information system designed for
them
(REPORTER: ABUDA)
The systems development life cycle (SDLC) is the process of creating or modifying
information systems to meet the needs of its users. The SDLC is generally viewed as the
foundation for all systems development that people use to develop such systems. It is a
conceptual model used in project management that describes the stages involved in an
information system development project, from an initial feasibility study through maintenance
of the completed application. SDLC can apply to technical and non-technical systems. In most
use cases, a system is an IT technology such as hardware and software. Project and program
managers typically take part in SDLC, along with system and software engineers, development
teams and end-users.
Every hardware or software system will go through a development process which can
be thought as an iterative process with multiple steps. SDLC is used to give a rigid structure
and framework to define the phases and steps involved in the development of a system.
The SDLC is a comprehensive framework that outlines the various stages involved in
the development of a software product. It serves as a structured approach to managing the
software development process, ensuring the efficient and effective delivery of the final product.
It is a well-defined, step-by-step process that organizations follow to develop and maintain
software systems. It serves as a blueprint for managing the entire software development
lifecycle, from the initial idea to the final product and beyond.
The SDLC is a framework that describes the steps involved in developing and
maintaining information systems. Here are the main phases of the SDLC:
• PLANNING PHASE - The planning phase of the SDLC begins with a business need
for a new or better information system. This phase involves summarizing the business
needs with a high-level view of the intended project. This is an initial phase involves
defining the project scope, identifying the problem to be solved, and establishing the
overall objectives and goals. It includes activities such as conducting feasibility studies,
gathering high-level requirements, and creating a project plan with timelines,
milestones, and resource estimates.
• ANALYSIS PHASE - The analysis phase of the SDLC involves a complete, detailed
analysis of the systems needs of the end user. In this phase, the requirements for the
system are gathered and analyzed. This includes understanding the current processes,
identifying the functional and non-functional requirements, and documenting the
system specifications. In this phase, the development team works closely with
stakeholders to gather, analyze, and document the detailed software requirements. This
includes understanding the user needs, defining the functional and non-functional
requirements, and identifying any constraints or dependencies.
• DESIGN PHASE - The design phase of the SDLC involves describing in detail the
desired features of the system that it uncovered in the analysis phase. The design phase
focuses on how the system will be built. This includes designing the system
architecture, user interfaces, data structures, and process flows. The design should meet
the requirements identified in the analysis phase. The design phase focuses on
translating the requirements into a technical solution. It involves designing the software
architecture, user interface, data structures, and algorithms. The output of this phase is
a comprehensive design specification that guides the implementation process.
• IMPLEMENTATION PHASE – It is also known as the coding or development phase,
this is where the software is actually built based on the design specifications.
Developers use various programming languages, frameworks, and tools to write the
code and integrate the different software components. The implementation phase of the
SDLC involves development, testing and implementation of the new proposed system.
Development is the process of transforming the plan from the design phase into an
actual, functioning system. In this phase, the new system is deployed and put into use.
This may involve user training, data migration, and transitioning from the old system
to the new one.
• MAINTENANCE PHASE - The maintenance phase of the SDLC is the final phase of
the SDLC and includes making changes, corrections, additions, and upgrades
(generally smaller in scope) to ensure the system continues to meet the business
requirements that have been set out for it. After the system is implemented, it requires
ongoing maintenance and support. This includes fixing bugs, making updates and
enhancements, and ensuring the system continues to meet the evolving needs of the
organization.
(REPORTER: DIAZ)
The table presents the success rates of IT projects for different years from 1994 to 2009.
The success rate refers to the percentage of projects that were completed successfully, without
encountering significant issues or failures. The challenged rate refers to the percentage of
projects that faced difficulties or encountered obstacles during their execution but were still
able to be completed. The failed rate refers to the percentage of projects that were not
completed successfully due to various reasons, such as project scope changes, budget overruns,
or other unforeseen issues.
For the year 2009, the table shows that 32% of IT projects were successful, 44% were
challenged, and 24% failed. This means that out of all the projects initiated in 2009, 32% were
completed without major issues, 44% faced difficulties but were still completed, and 24% were
not completed successfully due to various reasons.
The success, challenge, and failure rates for each year are based on industry trends and
historical data, and they can vary depending on various factors such as project management
practices, technology advancements, and economic conditions.
(REPORTER: SAMBAYON)
CONSTRAINTS OF IT PROJECTS
This image represents the triple constraints of IT project management, the scope, time
and cost.
• Scope: This refers to the defined boundaries of the project, including what needs to be
accomplished and the deliverables that will be produced. It outlines the work that needs
to be done to achieve the project's objectives. Managing scope involves controlling
changes to project requirements to ensure that the project stays on track.
• Time: Time refers to the project's duration or timeline. It includes the start and end
dates of the project as well as intermediate milestones. Managing time involves
scheduling tasks, tracking progress, and ensuring that the project is completed within
the specified timeframe.
• Cost: Cost refers to the financial resources required to complete the project. This
includes expenses such as labor, materials, equipment, and overhead. Managing cost
involves budgeting, tracking expenses, and controlling expenditures to ensure that the
project remains within budget.
These three factors are interrelated, meaning changes to one constraint will likely
impact the others. For example, extending the project timeline might increase costs, or
expanding the project scope could require more time and resources. Balancing these constraints
is essential for successful project delivery.
Overall, the triple constraints framework helps ensure that projects are completed
successfully, meeting stakeholder expectations in terms of quality, timeliness, and budget.
USEFUL RULES IN PROJECT MANAGEMENT
Example:
Let's say a software development team is tasked with creating a new mobile application.
The 100% rule would require them to meticulously plan every aspect of the project, including:
• Defining project goals and objectives.
• Identifying all the features and functionalities required for the app.
• Breaking down each feature into smaller tasks. Assigning responsibilities to
team members.
• Estimating time and resources needed for each task.
• Anticipating potential risks and creating contingency plans.
• Setting milestones and deadlines for completion.
• Ensuring clear communication channels within the team and with stakeholders.
By following the 100% rule, the team can minimize the chances of overlooking critical
tasks or encountering unexpected challenges during the development process.
While In 15-15 rule, A software development project was initially estimated to take six
months to complete with a budget of $100,000. However, halfway through the project, the team
realizes that they are already eight months in, and the costs have escalated to $120,000.
According to the 15-15 rule, the project is over the budget threshold and significantly off
schedule. This would prompt the project manager to investigate the reasons for the delays and
cost overruns and take corrective actions, such as reallocating resources, revising the project
plan, or negotiating with stakeholders to adjust expectations.
In summary, the 100% rule ensures thorough planning and preparation, while the 15-
15 rule serves as a performance indicator, prompting timely intervention when projects veer
off track. Together, these rules contribute to effective project management and the successful
delivery of projects.
The GANTT chart and the PERT chart are probably the two best known visuals in
project management. Agile teams can use each of these charts for scheduling, but because Gantt
charts don't illustrate task dependencies and PERT charts can be confusing, project managers
often use both.
GANTT CHART
It is a graphical representation of the project schedule by mapping the tasks to a project
calendar. This horizontal bar chart displays tasks, or events, on the Y axis; they correspond to
a timeline on the X axis, to show the schedule for and dependencies between aspects of an
overall project. The chart's bars vary in length in accordance with how long the team estimates
that task will take. For example, in an application update, the requirements gathering task might
take longer than regression testing. Each bar's placement on the timeline provides start dates
and deadlines. Gantt charts show where tasks overlap, and where some team members will wait
for new work while others complete a step, which can help prevent inefficiencies. However,
these charts can get complex and long, especially when a project includes many discrete tasks.
Agile project managers can select Gantt chart builders, such as Team Gantt or Gantt
Project, and use plugins to bring these charts into collaboration platforms like Atlassian Jira.
Dynamic Gantt charts include progress bars, critical path visualization and other features. A
PERT chart shows dependencies with a sequence of lines, and tasks that must occur at the same
stage in the project with parallel lines. For example, development followed by unit testing are
sequential tasks, while parallel tasks might be user acceptance testing and marketing materials
creation. The PERT chart should include indicators of the sequence of tasks and estimated time
to reach each milestone.
PERT CHART
A PERT Chart it works to identify all tasks of a project
– Notes task sequencing and task dependence.
– Notes critical path – the path that represents the minimum amount of time needed
for the completion of the project when sufficient resources are allocated. Pert chart can include
the project's critical path and other features. PERT charts show task sequences at a glance, they
aren't simple to construct, and adopters should learn time estimation methods and ways to track
resources assigned to tasks. Software development project managers can generate PERT charts
in visualization tools, such as Lucid chart and Microsoft Visio, and integrate these charts with
collaboration tools like Slack.
The Technology Acceptance Model | Smart Insights
The Technology Acceptance Model (TAM) is a theory that explains how people learn
to accept and use new technology, such as hardware, software, or online learning communities.
The model was developed by Fred Davis at the University of Michigan in 1986 and is based
on the Theory of Reasoned Action, which provides a psychological perspective on human
behavior.
The TAM suggests that two factors primarily influence a person's decision to adopt new
technology:
• Perceived usefulness: How useful the person perceives the technology to be
• Perceived ease of use: How easy the person perceives the technology to be to
use
The model emphasizes the importance of the potential user's perceptions, and that the
technology won't be accepted unless the user shares those perceptions. For example, college
students might perceive online therapy as useful, which could influence their decision to use
it.
The TAM has been widely applied by information systems scholars to help
organizations promote the acceptance of new information systems. However, the findings
reported on the model are mixed in terms of statistical significance, direction, and magnitude.
REFERENCES
https://www.techtarget.com/searchsoftwarequality/definition/systems-development-life-
cycle
ciadmin,+Journal+manager,+1639-6496-1-CE