IT314 Software Engineering

AAROGYA
SDLC Model v1.0

Instructor: Prof. Pranav Joshi

AAROGYA Team 13

IT314 Software Engineering

Document Description:
The goal of this phase is to decide a suitable SDLC Model for our project. Choosing a life cycle model will help in proper functioning of the development of the product.

Revision History
Date
12th Feb 2014

Document
SDLC Model

Version
1.0

Created By Reviewed By
Vipul , Pavithra Nikhil, Satyam

AAROGYA

Team 13

IT314 Software Engineering

Table of Contents
Project Objective: .............................................................................................. 4 Document Conventions4 Software Development Life Cycle (SDLC): ...................................................... 4 Waterfall Model:.................................................................................................. 5 -Merits: .......................................................................................................6 -Demerits: ................................................................................................. 6 -Reasons for REJECTING: ........ 7 Iterative Model: ............................................................................................... 7 -Merits:....................................................................................................... 8 -Demerits: ................................................................................................. 8 -Reasons for ACCEPTING: ..... 9 Spiral Model: ...................................................................................................... 9 -Merits: .................................................................................................... 10 -Demerits: ............................................................................................... 10 -Reasons for REJECTING:.........10 Scrum Model: ................................................................................................ 10 -Scrum Software Development Methodology11 -Merits: .....................................................................................................12 -Demerits: ................................................................................................12 -Reasons for REJECTING: .12 Conclusion: .......................................................................................................13

AAROGYA

Team 13

IT314 Software Engineering

Project Objective:
We have proposed to build a website for the health care management system. The system will have three sets of users: the medical store owner, doctors, and patients. The medical stores can use this website to hold a record of all the stock inventories of the store, which can be updated by the store owner. The patients can use this website to maintain their treatment history and all their lab reports online. The doctor can use this website to have look at a patients medical history who has come to him for treatment. The doctor can also schedule his appointments on this website.

Document Conventions:
The following conventions would be followed throughout the document:

Title: Arial, 72, Bold, Blue Heading 1: Arial , 20, Bold, Blue Heading 2: Arial, 16, Bold, Light Blue Heading 3: Arial, 14, Bold, Underlined, Light Blue Body: Times New Roman, 12, Black

Software Development Life Cycle (SDLC)

The Software Development Life Cycle (SDLC) is a framework defining tasks performed at each step in the software development process. SDLC is the process, consisting of a series of planned activities, used by software industry to design, develop and test high quality softwares. The SDLC aims to produce a high quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates. Software Development Life Cycle refers to the series of identifiable phases that software undergoes during its lifetime. These various life cycle phases includes: Feasibility Requirement Specifications Design Coding & Unit Testing Integration Testing Maintenance

AAROGYA

Team 13

IT314 Software Engineering

Since different types of projects have different requirements. Therefore, it may be required to choose the SDLC phases according to the specific needs of the project. These different requirements and needs give us various software development approaches to choose from during software implementation. Due to importance of the Software Development Life Cycle, various models have been proposed. Large development teams cannot function without formal definitions of work. Defining life cycle model encourages development of software in systematic and disciplined manner. Following are the most important and popular SDLC models followed in the industry: Waterfall Model Iterative Model Spiral Model Scrum Model

Waterfall Model
Waterfall model is the earliest SDLC approach that was used for software development. The waterfall Model illustrates the software development process in a linear sequential flow; hence it is also referred to as a linear-sequential life cycle model. This means that any phase in the development process begins only if the previous phase is complete and the outcome of one phase acts as the input for the next phase sequentially. In waterfall model phases do not overlap. The sequential phases in Waterfall model are: Requirement Gathering and analysis System Design Implementation Integration and Testing Deployment of system Maintenance

AAROGYA

Team 13

IT314 Software Engineering

Merits
-Works well for smaller projects where requirements are very well understood. -Easy to understand and follow -Phases are processed and completed one at a time. -Verification at each stage ensures early detection of errors / misunderstanding -Process and results are well documented.

Demerits
-Inflexible: requirements cannot be changed once defined -Software is generated much later in the software cycle -High level of risk and uncertainty involved -It is difficult to measure progress within stages -Poor model for long and ongoing projects

AAROGYA

Team 13

IT314 Software Engineering

Reasons for REJECTING this model

Waterfall development does not allow for much revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not welldocumented or thought upon in the concept stage. But requirements in our project are at a high risk of changing. We cannot accommodate changing requirements in this model. It is difficult to measure progress within stages. In our website, we have planned to implement step by step, i.e. first develop the user interface for doctor, then for patient and then for medical store. But there are many features where both the doctor and patients account will interact with each other. Similarly there will be interaction between patient and medical store and the store and doctors. The coding of these steps will be possible only after the integration of the three sub sections of the website. This means we have to go back in the waterfall model which is not desirable. No working software is produced until late in the life cycle. As seen above working website will produced only after integration of the three sub sections of the website which comes very late in the life cycle. Integration is done as a "big-bang at the very end of the project which doesn't allow identifying any technological or business challenges early. So we cant integrate part by part and then code further. We will have do all the coding first and then integrate all the segments which would result in lot of bugs and many changes in code.

Iterative Model
The iterative model uses multiple cycles and an incremental approach for developing a system. Iterative process starts with a simple implementation of a subset of the software requirements and iteratively enhances the evolving versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added. The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental).

AAROGYA

Team 13

IT314 Software Engineering

The key to successful use of an iterative software development lifecycle is rigorous validation of requirements, and verification & testing of each version of the software against those requirements within each cycle of the model. As the software evolves through successive cycles, tests have to be repeated and extended to verify each version of the software.

Merits
-Output is generated after each stage, therefore it has high visibility. -Amount of rework is minimized. -Timely evaluation of each and every artefact generated. -Less costly to change the scope/requirements. -Testing and debugging during smaller iteration is easy.

Demerits
-Amount of time spent on testing is high. -Even a small change in any previous stage can cause big problem for subsequent phases as all phases are dependent on each-other -Applicable only to large and bulky software development projects. This is because it is hard to break a small software system into further small serviceable increments/modules -Partitioning the functions and features might be problematic - Integration between iteration can be an issue if this is not considered during the development.

AAROGYA

Team 13

IT314 Software Engineering

Reasons for ACCEPTING this model

The advantage of this model is that there is a working model of the system at a very early stage of development which makes it easier to find functional or design flaws. Parallel development can be planned. Less costly to change the scope/requirements. Testing and debugging during smaller iteration is easy. Risks are identified and resolved during iteration; and each iteration is an easily managed milestone. Easier to manage risk - High risk part is done first. With every increment operational product is delivered. Issues, challenges & risks identified from each increment can be utilized/applied to the next increment. It supports changing requirements.

Spiral Model
Spiral model is a combination of iterative development process model and sequential linear development model i.e. waterfall model with very high emphasis on risk analysis. It allows for incremental releases of the product, or incremental refinement through each iteration around the spiral. In each iteration of the spiral approach, software development process follows the phase-wise linear approach. At the end of first iteration, the customer evaluates the software and provides the feedback. Based on the feedback, software development process enters into the next iteration and subsequently follows the linear approach to implement the feedback suggested by the customer. The process of iteration continues throughout the life of the software. The spiral model has four phases: Planning Risk Analysis Engineering Evaluation.

AAROGYA

Team 13

IT314 Software Engineering

10

Merits
- Changing requirements can be accommodated. -Software is produced early in the software life cycle. -Requirements can be captured more accurately. -Development can be divided into smaller parts and more risky parts can be developed earlier which helps better risk management.

Demerits
-End of project may not be known early. -Spiral may go indefinitely -Risk analysis requires highly specific expertise. -Projects success is highly dependent on the risk analysis phase. -Large number of intermediate stages requires excessive documentation

Reasons for REJECTING this model

Spiral model is very similar to Iterative Model. Risk Analysis is the most significant feature of the Spiral Model which is not in Iterative Model. When there is a budget constraint, risk evaluation is important. Our project has less risks assessment involved. We require iterative development without risk analysis. So Iterative Model is good enough for our project. Also Spiral Model may go infinitely which is not desirable.

Scrum Model
SCRUM is a management, enhancement and maintenance methodology for an existing system or production prototype. SCRUM initially plans the context and broad deliverable definition, and then evolve the deliverable during the project based on the environment. SCRUM acknowledges that the underlying development processes are incompletely defined and uses control mechanisms to improve flexibility.

AAROGYA

Team 13

IT314 Software Engineering

11

The Scrum Software Development Methodology

A product owner creates a prioritized wish list called a sprint backlog. During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces. The team has a certain amount of time, a sprint, to complete its work usually two to four weeks but meets each day to assess its progress (daily scrum). Along the way, the Scrum Master keeps the team focused on its goal. At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store shelf, or show to a stakeholder. The sprint ends with a sprint review and retrospective. As the next sprint begins, the team chooses another chunk of the product backlog and begins working again. The cycle repeats until enough items in the product backlog have been completed, the budget is depleted, or a deadline arrives. Which of these milestones marks the end of the work is entirely specific to the project. No matter which impetus stops work, Scrum ensures that the most valuable work has been completed when the project ends.

AAROGYA

Team 13

IT314 Software Engineering

12

Merits
It is a lightly controlled method which insists on frequent updating of the progress in work through regular meetings. Thus there is clear visibility of the project development. This is also iterative in nature. It requires continuous feedback from the user. Due to short sprints and constant feedback, it becomes easier to cope with the changes. Daily meetings make it possible to measure individual productivity. This leads to the improvement in the productivity of each of the team members. Issues are identified well in advance through the daily meetings and hence can be resolved in speedily. It is easier to deliver a quality product in a scheduled time. The overhead cost in terms of process and management is minimal thus leading to a quicker, cheaper result.

Demerits
Scrum is one of the leading causes of scope creep because unless there is a definite end date, the project management stakeholders will be tempted to keep demanding that new functionality be delivered. If a task is not well defined, estimating project costs and time will not be accurate. In such a case, the task can be spread over several sprints. If the team members are not committed, the project will either never complete or fail. It is good for small, fast moving projects as it works well only with small team. This methodology needs experienced team members only. If the team consists of people who are novices, the project cannot be completed in time. Scrum works well for project management when the Scrum Master trusts the team they are managing. If they practice too strict control over the team members, it can be extremely frustrating for them, leading to demoralization and the failure of the project. If any of the team members leave during a development it can have a huge inverse effect on the project development

Reasons for REJECTING this model

This model requires excessive documentation as it demands the mention of the details of every sprint planning meeting, daily scrum meeting and sprint retrospective meeting which is very cumbersome. Very few of our team members have worked on any website developing project before this. So, initial sprints would be very slow and daily sprint meetings would not be

AAROGYA

Team 13

IT314 Software Engineering beneficial as most of the members would be more focused on adopting the web technologies instead of actually developing the website.

13

Conclusion
After studying all the SDLC models, the model we have chosen for our project is the Iterative Model. The classical waterfall model assumes certain amount of experience and confidence in the developer team. As a team of Software Engineering students, implementing this model is too risky as most of our team members are new to web development tools. Our project is not serving the requirements of one particular user from whom we could get the prototype reviewed. The prototype model works best with a system with maximum user interaction. The spiral model appears to be very complex. It requires competent professional management. Also risk assessment is an integral part of this model. But our project does not require risk analysis. Thus, again not a very appropriate model for our project. Using the Scrum Methodology helps break our project into smaller, manageable parts. But it can be difficult for the Scrum master to plan, structure and organize a project that lacks a clear definition. In addition, frequent changes, frequent product delivery and uncertainty regarding the precise nature of the finished product make for a rather intense project life cycle for everyone involved. Furthermore, the daily Scrum meetings and frequent reviews require substantial resources. A successful project depends on the maturity and dedication of all participants, and their ability to maintain consistently high levels of communication through each backlog and review. The Iterative model seems to be the model best suited for our project. We can plan the project out in iterations, by setting deadlines for each phase. Also, the iterative model takes care of risks and changing requirements. As our product is meaningful for more than one user, requirements can vary at some later stage. Hence, iterative model fits best for our project.

AAROGYA

Team 13