ISI3195_Sofware Engineering – INGE3_ISI

Instructor: Ytembe Dankam Therese

I. Solution/Process Model Life Cycle

The solution lifecycle is a step-by-step framework of best practices used to shepherd a project from its
beginning to its end. It provides project managers a structured way to create, execute, and finish a
project.

This project management process generally includes four phases: initiating, planning, executing, and
closing. Some may also include a fifth “monitoring and controlling” phase between the executing and
closing stages. By following each step, a project team increases the chance of achieving its goals.

1. Initiating

In the initiation phase, you’ll define the project. You’ll sort out the project goals, scope, and resources of
the project, and what roles are needed on the team. Clarifying what stakeholders expect out of the project,
and what exactly the project is aiming to achieve (and why) will give the project and team clear direction.

This is a crucial phase to the project’s success. Without clarity around what needs to be achieved and why,
the project runs the risk of not accomplishing the end goals and meeting the expectations of stakeholders.

Some steps in the initiation phase include:

 Communicating with stakeholders to understand the purpose and desired outcomes of the project
 Identifying project scope
 Determining SMART goals (specific, measurable, achievable, relevant, and time-bound)
 Clarifying resources like budget and time constraints
 Confirming team size and roles required
 Determining how often and which stakeholders will be involved throughout the project
 Compiling a project proposal and project charter

Tools and documents used in the initiation phase can include:

 Project proposal: The project proposal defines a project and outlines key dates, requirements, and goals.
 Project charter: This is a definitive document that describes the project and main details necessary to
reach its goals. This can include potential risks, benefits, constraints, and key stakeholders.
 RACI chart: A RACI chart plots the roles and responsibilities of members on a project team.

2. Planning

In the planning phase, you’ll determine the steps to actually achieve the project goals—the “how” of
completing a project.

You’ll establish budgets, timelines, and milestones, and source materials and necessary documents. This
step also involves calculating and predicting risk, putting change processes into place, and outlining
communication protocols. If the initiation phase is assembling your troops, the planning phase is deciding
what to do with them.

The planning phase can include the following steps:

 Deciding on milestones that lead up to goal completion
 Developing a schedule for tasks and milestones, including time estimates and potential time buffers
 Establishing change processes
 Determining how and how often to communicate with team members and stakeholders
 Creating and signing documents such as non-disclosure agreements (NDAs) or requests for proposal
(RFPs)
 Assessing and managing risk by creating a risk register
 Holding a kick-off meeting to start project

Tools you might use in this phase include:

 Gantt chart: A horizontal bar chart in which members can see what tasks must be completed in what
order, and how long each is expected to take
 Risk register: A chart that lists risks associated with the project, along with their probability, potential
impact, risk level, and mitigation plans

3. Execute and complete tasks

Executing a project means putting your plan into action and keeping the team on track. Generally this
means tracking and measuring progress, managing quality, mitigating risk, managing the budget, and using
data to inform your decisions.
 Specific steps might include:
 Using tools like GANTT or burndown charts to track progress on tasks
 Responding to risks when they manifest
 Recording costs
 Keeping team members motivated and on task
 Keeping stakeholders informed of progress
 Incorporating changes via change requests

Some tools you might use include:

 Change requests: These are documents used to propose changes to a project’s scope or goals
 Burndown chart: This chart breaks down tasks on a granular level and visualizes the amount of time
remaining

4. Close projects

In the closing phase of the project management lifecycle, you’ll conclude project activities, turn the
finished product or service over to its new owners, and assess the things that went well and didn’t go so
well. It’ll also be a time to celebrate your hard work.

Steps in the closing phase can include:

 Conducting retrospectives and take notes of changes you can implement in the future
 Communicating to stakeholders of the end of the project and providing an impact report
 Communicating with the new owners of a project
 Creating a project closeout report
 Celebrating the end of the project and your successes

Tools used in the closing phase include:

 Impact report: This report compiles a series of metrics that showcase how your project made a difference
and is presented to your stakeholders.
 Project closeout report: A project closeout report provides a summary of your project’s
accomplishments, and provides key learnings for future project managers to reference.
 II. The Software Development Life cycle

Software Processes is a coherent set of activities for specifying, designing, implementing and testing
software systems. A software process model is an abstract representation of a process that presents a
description of a process from some particular perspective. There are many different software processes
but all involve:
 Requirements Specification – defining what the system should do;
 Design and implementation – defining the organization of the system and implementing the
system;
 Validation – checking that it does what the customer wants;
 Evolution – changing the system in response to changing customer needs.

Assignment: Read on make short notes on:

 Operating Systems
 Utility Software

III. Traditional Software Models

Software development is a challenging and demanding profession. The increased complexity of

software projects, time constraints, and lack of resources often lead to frustration for engineers on
the job.

Waterfall

The first published model of the software development process was derived from engineering
process models used in large military systems engineering (Royce 1970). It presents the
software development process as a number of stages, as shown below. Because of the cascade
from one phase to another, this model is known as the waterfall model or software life cycle.
The waterfall model is an example of a plan-driven process.
In principle, the result of each phase in the waterfall model is one or more documents that are
approved (“signed off”). The following phase should not start until the previous phase has
finished. For hardware development, where high manufacturing costs are involved, this makes
sense. However, for software development, these stages overlap and feed information to each
other. During design, problems with requirements are identified; during coding design problems
are found, and so on. The software process, in practice, is never a simple linear model but
involves feedback from one phase to another.

Incremental Model

Incremental development in some form is now the most common approach for the development of
application systems and software products. This approach can be either plan-driven, agile or, more
usually, a mixture of these approaches. In a plan-driven approach, the system increments are identified
in advance; if an agile approach is adopted, the early increments are identified, but the development of
later increments depends on progress and customer priorities. Incremental software development, which
is a fundamental part of agile development methods, is better than a waterfall approach for systems
whose requirements are likely to change during the development process. This is the case for most
business systems and software products. Incremental development reflects the way that we solve
problems. We rarely work out a complete problem solution in advance but move toward a solution in a
series of steps, backtracking when we realize that we have made a mistake. By developing the software
incrementally, it is cheaper and easier to make changes in the software as it is being developed.
V shape Model

The V-model is a type of SDLC model where process executes in a sequential manner in V-shape. It
is also known as Verification and Validation model. It is based on the association of a testing phase
for each corresponding development stage. Development of each step directly associated with the
testing phase. The next phase starts only after completion of the previous phase i.e. for each
development activity, there is a testing activity corresponding to it.

The V-Model is a software development life cycle (SDLC) model that provides a systematic and
visual representation of the software development process. It is based on the idea of a “V” shape, with
the two legs of the “V” representing the progression of the software development process from
requirements gathering and analysis to design, implementation, testing, and maintenance.
Spiral Model

The Spiral Model is one of the most important Software Development Life Cycle models, which
provides support for Risk Handling. In its diagrammatic representation, it looks like a spiral with
many loops. The exact number of loops of the spiral is unknown and can vary from project to project.
Each loop of the spiral is called a Phase of the software development process.

It provides a systematic and iterative approach to software development. It is based on the idea of a
spiral, with each iteration of the spiral representing a complete software development cycle, from
requirements gathering and analysis to design, implementation, testing, and maintenance.

Phases of the spiral model

 Planning: The first phase of the Spiral Model is the planning phase, where the scope of the
project is determined and a plan is created for the next iteration of the spiral.
 Risk Analysis: In the risk analysis phase, the risks associated with the project are identified and
evaluated.
 Engineering: In the engineering phase, the software is developed based on the requirements
gathered in the previous iteration.
 Evaluation: In the evaluation phase, the software is evaluated to determine if it meets the
customer’s requirements and if it is of high quality.
 Planning: The next iteration of the spiral begins with a new planning phase, based on the results
of the evaluation.
 The Spiral Model is often used for complex and large software development projects, as it
allows for a more flexible and adaptable approach to software development. It is also well-
suited to projects with significant uncertainty or high levels of risk.

Component Based Model

Component-Based Software Engineering (CBSE) is a process that focuses on the design and
development of computer-based systems with the use of reusable software components.
It not only identifies candidate components but also qualifies each component’s interface, adapts
components to remove architectural mismatches, assembles components into a selected architectural
style, and updates components as requirements for the system change.

The process model for component-based software engineering occurs concurrently with component-
based development.
Component-based development:
Component-based development (CBD) is a CBSE activity that occurs in parallel with domain
engineering. Using analysis and architectural design methods, the software team refines an
architectural style that is appropriate for the analysis model created for the application to be built.
 Major CBSE processes include;

 Component Qualification
 Component development
 Component integration
 Component support

Assignment: Make shot notes on the iterative model, clearly bringing out the
difference between iterative and incremental models.

IV. Other Techniques

Engineering is all about selecting the most appropriate method for a set of circumstances, so a more
creative, less formal approach to development may be the right one for some kinds of software. A more
flexible software process that accommodates rapid change is particularly appropriate for the
development of interactive web-based systems and mobile apps, which require a blend of software and
graphical design skills.

Prototyping

JAD

JAD (Joint Application Development) is a software development approach that engages the client and/or
the end-users to design and develop the system. This model was designed and put forward by Dr. Chuck
Morris and Dr. Tony Crawford of IBM, who propose this model in the late 1970s. As compared to other
primitive SDLC models, the Joint Application Development model leads to faster progression of the
system development, which has better client approval.

This model, furthermore, is vast when it comes to agile delivery wherein the software products need to
be developed as well as shipped in short iterations depending on agreements among the industrial as
well as industry stakeholders, which are termed as Minimum Viable Product (MVP).
Phases of the JAD MODEL

1. Define Specific Objectives: The facilitator, in partnership with stakeholders, sets all the
objectives and a list of items, which is then distributed to other developers and participants to
understand and review. This objective contains elements like the scope of this projected system,
its potential outcome, technical specifications required, etc.
2. Session Preparation: The facilitator is solely responsible for this preparation, where all relevant
data is collected and sent to other members before time. For better insight, research is carried
out to know the system requirement better and gather all the necessary information for
development.
3. Session Conduct: Here, the facilitator is accountable for identifying those issues that have to be
working out to make the system error-free. Here the facilitator will serve as a participant but
will not have a say regarding any information.
4. Documentation: After the product is developed, the records and published documents are put
forward into the meeting so that the stakeholders and consumers can approve it through the
meeting.

UP

The Unified Process recognizes the importance of customer communication and streamlined methods
for describing the customer’s view of a system. It emphasizes the important role of software architecture
and “helps the architect focus on the right goals, such as understandability, reliance to future changes,
and reuse”.

Phases of the Unified Process

This process divides the development process into five phases:

 Inception
 Elaboration
 Conception
 Transition
 Production

The inception phase of the UP encompasses both customer communication and planning activities. By
collaborating with stakeholders, business requirements for the software are identified; a rough
architecture for the system is proposed; and a plan for the iterative, incremental nature of the ensuing
project is developed.

The elaboration phase encompasses the communication and modeling activities of the generic process
model.

Elaboration refines and expands the preliminary use cases that were developed as part of the inception
phase and expands the architectural representation to include five different views of the software the use
case model, the requirements model, the design model, the implementation model, and the deployment
model.

Elaboration creates an “executable architectural baseline” that represents a “first cut” executable system.
The construction phase of the UP is identical to the construction activity defined for the generic software
process. Using the architectural model as input, the construction phase develops or acquires the software
components that will make each use case operational for end users.

To accomplish this, requirements and design models that were started during the elaboration phase are
completed to reflect the final version of the software increment. All necessary and required features and
functions for the software increment (the release) are then implemented in source code.

The transition phase of the UP encompasses the latter stages of the generic construction activity and the
first part of the generic deployment (delivery and feedback) activity.

Software is given to end users for beta testing and user feedback reports both defects and necessary
changes. At the conclusion of the transition phase, the software increment becomes a usable software
release.

The production phase of the UP coincides with the deployment activity of the generic process. During
this phase, the ongoing use of the software is monitored, support for the operating environment
(infrastructure) is provided, and defect reports and requests for changes are submitted and evaluated.

RAD

Rapid Application Development or RAD means an adaptive software development model based on
prototyping and quick feedback with less emphasis on specific planning. In general, the RAD approach
prioritizes development and building a prototype, rather than planning. With rapid application
development, developers can quickly make multiple iterations and updates to the software without starting
from scratch. This helps ensure that the final outcome is more quality-focused and aligns with the end users’
requirements.
RAD was conceived in the 1980s, so it’s definitely not something new. But unlike the waterfall model,

it’s not singular. It’s a continuous evolution of development philosophies according to the requirement at

that particular time. The worldwide market for Rapid Application Development is projected to grow at a

compound annual growth rate (CAGR) of 42.8% from 2022 to 2027

Assignment:

Make short notes on personal and team software processes (psp/tsp) clearly differentiating the 2 more
approaches with regards to method of implementation.