SDLC MODELS:

Code & Fix: Jumping right in and designing the system, only to fix any problems along the
way. There usually is no planning or organizing before the work begins

Con→ Because you rush in and begin designing and developing, big problems can occur
later in the project. Oftentimes this means going back and redoing a step which
costs time and money.
● Less common, seldom useful, simple
● Requires little expertise
● No overhead, good for small projects
● Poor structure
● Time saver, need results fast
● Small projects and teams, easy to understand if new to code

Code (cook pizza) → test & debug (check if pizza is cooked)-->delivery (send)
→ if errors (pizza is raw)
- No design
- No specifications
- Requires little expertise
- No overhead
- Good for small projects

- Subsequent fixes become expensive

- Poor structure

First version -> modify -> post delivery maintenance -> retirement

Sashimi Model: (agile method)

Waterfall model modification with overlapping phases - japanese style

Strengths:
- More efficient (less documentation)
- Documentation for requirements can be more accurate because of overlapping
-less people working on the project, same people working on the project throughout
each phase
Weaknesses:
- Harder to track progress
- Lead to miscommunication, mistaken assumptions, and inefficiency
Deadlines may be unclear

● Projects: small, that are well defined

● Works best when team members have high level of expertise
●

Staged Delivery:
Allows for products to become deliverable at every stage. a lifecycle model in
which the developers deliver their software to the clients in successive stages
throughout the whole development. (This model is also known as “incremental
implementation”)

Strengths
- Learn from earlier versions
- Deliver product in increments
-flexibility in development, makes changes less expensive
- Potential errors and misunderstandings of objective can be easily found and
addressed earlier in the development process.
-Clients can review and provide constructive feedbacks for each build
-Can generate a working software more quickly
-Easier to test and debug
-Allows for useful functionalities to be delivered earlier than delivering 100% of the
project at the end
-Customers may be able to start using software earlier if stages are planned
carefully
 Weaknesses
- Will not work without planning at both management and technical levels
Requirement -> Planning -> Implementation and Testing -> Closure

-Waterfall-like beginnings, then develop in short release cycles: plan, design,

execute, test, release, with delivery possible at the end of any cycles

When is it used?
- Requirements and goals are clear and defined. It’s also used when there is demand for an early
release of the product or when the goals are too ambitious/risky. This type of model is often used
for non-embedded applications and in product-based companies rather than software maintenance.
- Projects: phases to create a clearly defined plan for development, then need a more flexible, agile model
for the implementation, testing, and maintenance phases. The staged delivery model also helps with projects
where predictable and regular release cycles, and the ability to give regular feedback on progress, are desired
by a customer.

Spiral Model:

Determine Objectives -> Identify and resolve risks -> Development and Test -> Plan the
next iteration
(Lots of prototyping)

Strengths
- Risk-driven rather than document-driven
- Cost increase, risks decrease
- Good for where developers are unfamiliar with app domain or for critical systems

Weaknesses
- Complicated
- Difficult to indicate milestones whether you're ready to move to next layer
- Costly
Projects: projects with high risk, ambitious goals, and complexities requiring elements from other processes.
Large systems with broad usages are an example of such a project. Medium and smaller projects may not justify the
monetary cost of using the spiral model process, as it is quite costly to hire experienced risk analysis experts and
guarantee team cohesion to remain committed to the process.

Rational Unified Process (RUP): object-oriented models. Our visual is the Rational Unified Process (RUP)
that includes a life-cycle made up of five total phases.

Inception (vision) -> Elaboration -> Construction -> Transition (Deploy) -> Production

Strengths
- Emphasizes cohesive architecture early
- Risk and value driven
- Can be applied to any team size on life-critical systems
-Not concrete, more adaptable; the teams using this model will tailor it
to meet their client’s needs (so not a set in stone model like waterfall)
-Some characteristics of RUP include use-case driven, Iterative
(repetition of the process), and Incremental (increase in value) by
nature, delivered online using web technology, can be customized or
tailored in modular and electronic form, etc. RUP reduces unexpected
development costs and prevents wastage of resources.
-development team because they’re able to
access, plan, customize, execute, and evaluate their project.
Weaknesses
- complicated

Projects:
-best suited for development projects
of all types and sizes as it is a flexible and versatile process framework.

The Rational Unified Process has five stages in the Life Cycle. These 5 phases
are Inception, Elaboration, Construction, Transition, and Production.
Inception:
●
Communication and Planning are main goals to analyze the scope of the project
including the goals and risks that are involved.
Elaboration:
●
Planning and Modeling are main goals which checks for a detailed evaluation
and executes the project if it passes the milestone criteria.
Construction:
●
Project is now being developed and completed using source code. Testing is
done at the end after the code is created.
Transition:
●
Project is released to the public to enter the production phase for beta testing
and removing defects based on feedback received from the public.
Production:
●
Project is now in the final phase of the model for regular maintenance and
updates.

DSDM (Dynamic Systems Development Method) : Allows a more straightforward

approach to complex problem solving. Fixed is: time & resources, variable: functionality

- No design
- No specifications
- Requires little expertise
- No overhead
- Good for small projects

- Subsequent fixes become expensive

- Poor structure

First version -> modify -> post delivery maintenance -> retirement

Our visual shows the 9 principles of DSDM (Dynamic Systems Development Method)
1) Active user involvement – Imperative.
2) Teams must be empowered to make decisions.
3) Focus on frequent delivery.
4) Criterion for accepted deliverable (Fitness for Business).
5) Iterative and incremental development – Mandatory.
6) All changes during development must be reversible.
7) Requirements are base lined at high level.
8) Testing is integrated throughout the life cycle.
9) Collaborative and co-operative approach.

Projects: program, and portfolio management. DSDM shows the

full lifecycle of the project that used to develop a successful end result. DSDM allows
there to be clear and defined strategic goals that maintain focus and driven results.

1.Agile requires constant day-to-day communication between development teams and

business owners and users – if this is not possible Agile approaches may well struggle.

2.Where there are key interfaces (e.g. Supplier/ partners etc) ways of working must be
compatible and development teams must respect the needs of all stakeholders.

Examples of projects where Agile is suitable or may be possible:

1. Product development where a software company is developing a small or

medium-sized product for sale. Realistically all software products and apps are
now developed using an agile approach.

2. Custom system development within an organization, where there is a clear/strong

commitment from the customer to get involved in the development process and
where there are few outer stakeholders and protocols that affect the software.

DSDM Project Lifecycle:

-
Study: has two key stages: the feasibility study and the business study. Feasibility study:
The possibility of building the application is studied and the decisions are made.
Business study: business experts and the technical experts are discussing together about the problems in essential
business.
-
Functional model iteration: The requirements are finalized and built in incrementally. A plan is formed
to build the functionalities. Allocate all tasks.The prototype is created and tested to improve the product.
Then the end users are brought in to review the functionalities and tested to add in further improvements.
-
Design and build Integration: This phase initially begins with making certain that the
functionalities as built meet the user’s expectations and may operate effectively in the
sensible and operational environment.
-
This stages comprises of four stages:
1.
Identify design prototype
2.
Accept plan and schedule
3.
Create a design prototype
4.
Review the design prototype
-
Implementation: At this stage, it is available to end users. Feedback is collected from the
end users to make sure that the business demands are met and that the solution is correct.
Implementation is broken into these sub-parts:
1.
User approval and guidelines
2.
Train users
3.
Implement
LECTURES:

● Software engineering: engineering discipline concerned with all aspects of

software production
○ Organize teams, determine what to build, software architecture, analysis
and testing, lifecycle