0% found this document useful (0 votes)
42 views7 pages

Code and Fix Model in Software Development

The document discusses several software development lifecycle (SDLC) models: Code & Fix model is an informal model where development begins without planning and problems are fixed later. It is best for small, simple projects. The Sashimi model is an agile method that is a modified Waterfall model with overlapping phases. It has less documentation but risks of miscommunication. The Staged Delivery model delivers working software in stages throughout development for early feedback. It allows flexibility but requires careful planning. The Spiral model is risk-driven through prototyping. It is costly but good for complex, high-risk projects. The Rational Unified Process model includes iterative phases from inception to production

Uploaded by

fatima
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
42 views7 pages

Code and Fix Model in Software Development

The document discusses several software development lifecycle (SDLC) models: Code & Fix model is an informal model where development begins without planning and problems are fixed later. It is best for small, simple projects. The Sashimi model is an agile method that is a modified Waterfall model with overlapping phases. It has less documentation but risks of miscommunication. The Staged Delivery model delivers working software in stages throughout development for early feedback. It allows flexibility but requires careful planning. The Spiral model is risk-driven through prototyping. It is costly but good for complex, high-risk projects. The Rational Unified Process model includes iterative phases from inception to production

Uploaded by

fatima
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd

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.

[Link] requires constant day-to-day communication between development teams and


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

[Link] 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 [Link] 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

Common questions

Powered by AI

In the DSDM framework, user feedback is integral to every stage of development. The model emphasizes active user involvement and has mechanisms for iterative and incremental development, where users consistently review prototypes to ensure that the functionality meets their needs . This approach enables reversible changes during development and ensures that the end product aligns with business requirements by integrating testing and feedback throughout the lifecycle . Thus, user feedback not only ensures fitness for business but also minimizes risks of deviating from user needs .

DSDM's fixed time and resources approach ensures projects deliver essential functionalities within set constraints, enhancing focus and purposeful development . However, this rigidity may limit flexibility in accommodating changes if not managed well . Nevertheless, DSDM accommodates iterative, incremental development, which allows teams to align project outcomes closely with business needs while ensuring changes are reversible. Fixed constraints encourage efficiency, but might necessitate scope adjustments to meet project goals within time and resource boundaries .

RUP is a flexible and versatile process framework adaptable to projects of all sizes and complexities . It allows tailoring to meet specific project or client needs by incorporating object-oriented and use-case-driven methodologies . RUP's iterative and incremental nature enables teams to adapt processes, thereby reducing unexpected development costs and resource wastage. This flexibility, combined with its ability to emphasize risk and value, makes RUP applicable whether the project is small or life-critical systems, where cohesive architecture is vital .

The Spiral model is risk-driven and focuses on identifying and resolving risks before moving to the next development stage . It accommodates projects with high risk and complexity through extensive use of prototyping . The Rational Unified Process (RUP), in contrast, is risk and value driven, and emphasizes early architectural cohesion with an adaptable framework rather than a rigid model, allowing for more flexibility in addressing risks as they appear throughout the lifecycle . While both models aim to mitigate risks, Spiral is more proactive and tailored for projects with unknown domains or critical systems .

The Staged Delivery model differs from the Waterfall model by allowing software to be delivered incrementally in stages, encouraging early product release and client feedback throughout the development process . This approach contrasts with Waterfall, where project phases are strictly sequential. In Staged Delivery, planning involves anticipating multiple release cycles, while execution adapts to feedback and changing requirements, unlike Waterfall's rigid phase completion before moving forward . The model effectively combines Waterfall’s initial requirement and planning rigour with agile-like flexibility .

The Sashimi model, as an agile modification of the traditional Waterfall model, offers strengths such as increased efficiency and more accurate documentation due to overlapping phases . However, it can be harder to track progress, leading to miscommunication and inefficiency . Unlike Waterfall's sequential approach, Sashimi allows phases to overlap, which can accommodate a higher expertise among team members but might complicate deadline clarity .

The Code & Fix model may be suitable for small projects requiring swift results where little expertise or overhead is required, making it easy to understand for newcomers . However, it is crucial to consider the lack of planning or structure, which can lead to expensive fixes later on as the model does not anticipate problems upfront . This model's simplicity can turn detrimental for larger projects with complex requirements . Therefore, its use should be limited to small teams and projects with very clear, unchanging requirements .

Teams using the Sashimi model might struggle with tracking progress due to overlaps in phases, potentially leading to miscommunication and inefficiency . Deadlines might be unclear, complicating project management. To mitigate these issues, teams should establish clear communication channels, ensure cohesive documentation of requirements, and adopt robust tracking tools. Maintaining a high level of expertise on the team can also help manage the model's demands for continuous and concurrent development processes .

The Code & Fix model does not involve any planning or design before the work begins, which can lead to major issues later in the project that require time-consuming and costly revisions . Conversely, the Staged Delivery model involves planning at both management and technical levels, which helps identify and address potential errors and misunderstandings earlier in the process . The lack of structure in Code & Fix makes it simple yet risky for any corrections needed, while Staged Delivery promotes learning from earlier versions and provides incremental flexibility .

The Spiral model is preferred in scenarios involving high-risk projects, ambitious goals, and significant complexities requiring comprehensive risk management and prototyping . It is particularly effective in large systems with broad usage, where risk factors are unknown or the project is critical, such as in the development of new technologies or systems with significant domain unfamiliarity . Due to its cost implications, it's generally less suitable for medium and smaller projects unless the complexity justifies the investment in risk analysis expertise .

You might also like