1
Q
Generally termed as SDLC. is the conceptual framework which clearly defines what tasks must be performed at each stage and by whom, within scheduled timeframe and at operational cost.
A
SOFTWARE DEVELOPMENT LIFE CYCLE
2
Q
WHY IS SOFTWARE DEVELOPMENT LIFE CYCLE NECESSARY?
A
- Enhance the quality of the software
- Define the goals to the team so that developers know what to build and testers know what and how to test
- Reduce the rate of vulnerabilities (fewer or none)
- Management control
- Effective documentation and reduced dependencies
- Effective resource utilization
- Effective cost and time definition
- Ensure the architecture and design are secure
- Define and adhere to the set processes and objectives
- Meet and exceed Customer’s expectations
3
Q
Software Development Life Cycle Stages
A
- Project Kickoff / Project Initiation
- Requirements Gathering
- Analysis
- Design
- Development
- Testing
- Deployment
- Operation and Maintenance
4
Q
- The first stage in Software Development Life Cycle where the project is initiated.
- High-level scope, problems, and solutions are determined and planning is carried out accordingly for other stages.
A
Project Kickoff / Project Initiation
5
Q
Here two things are mainly focused:
* What is needed?
* What is not needed?
In “What is needed?” part, the requirements are further analyzed to understand what are:
* Functional Requirements
* Non-functional Requirements
A
Requirements Gathering
6
Q
Requirements can be gathered using the following tools/techniques:
A
- Interviews
- Workshops
- Surveys and questionnaires
- Focus Groups
- Observations/time study
- Brainstorming Sessions
- Document Analysis (Ex: Regulatory requirements)
- Mind Mapping
- Benchmarks
7
Q
- In this stage we analyze each and every achievable requirement.
- These are documented as Software Requirements Specifications (SRS) or Functional Requirements Specifications (FRS).
- Risks are predicted and the action items to mitigate those risks are well-planned at this stage.
- Also, each and every user requirement are analyzed to ensure that they can be met.
A
Analysis or System Analysis
8
Q
- This is the stage which states “How to achieve what is needed?”
- Software Requirements Specifications (SRS) are now converted to the system design plan, which is commonly known as “Design Specification”.
*All the technical details like technologies to use, project constraints, team’s capability, etc goes into the design specification document.
- The technical architects and developers develop the logical plan of the system which is then reviewed by all the stakeholders.
- The feedback and suggestions collected from the stakeholders are again incorporated into the already developed logical plan.
A
System Design
9
Q
This stage in simpler terms is where the “real work begins” and we “build what is needed”.
- The developers start to code as per the requirements and the developed design.
- Along with the coding, all the other required set-up will begin. i.e., the database set up by database admin, interface, and GUI creation by front-end developers, etc.
- Along with coding, it is also important for developers to develop unit tests for their module, peer review other module’s unit tests, deploy builds to the intended environment and execute unit tests.
A
Development
10
Q
- This stage is the one where the quality check takes place. The developed software is assessed to ensure that all the specified requirements are met.
- This is performed by testing team and the focus is to find the defects.
- During test case execution, all the defects found are reported in the test management tool and the decision of considering the defect as Valid or Invalid depends on developers.
- If the defect is Invalid, it is just rejected and closed.
- If the defect is Valid, then it is fixed in the code by the developer and the code fix is provided in the next build for the tester to test whether the defect is fixed or not.
- Each defect that is found will have to go through the Defect Life Cycle in the defect management tool.
- Again, the testing approach that the project choose depends on various factors: complexity of the project, team’s capability, time, etc.
A
Testing
11
Q
- Once the testing is completed and there are no open high priority issues, then comes the time to deploy the build to the Production environment.
- This is the environment which is accessible by real users. Real users
can then use the software as per their needs.
A
Deployment
12
Q
- This stage is when the “fine tuning” of the software takes place.
- Once the build is deployed to Production environment, any issues that the real users face are considered as post-Production issues.
- These Post-Production issues are addressed and resolved by the internal team usually termed as Maintenance team.
- This stage also addresses minor change requests, code fixes, etc. and deploys them in short intervals.
A
Operation and Maintenance
13
Q
are the conditions that are required to begin the processing of the current stage.
A
Entry criteria
14
Q
are the conditions which sets the stage as completed so that the next stage comes into action.
A
Exit criteria
15
Q
- Known as Linear sequential Model.
- It’s called this model because all the stages in the Software Development Life Cycle are followed step by-step and there is no going back between the stages.
- This is the very rigid structure where until completion of the current stage the next stage cannot be started.
- The outcome of the current stage acts as input to the next stage and there is no overlapping of the stages.
- If at all there is any changes in requirements to be handled, then there is no process that defines how to go back to the previous stages(s) to handle it.
- The current cycle must be completed and then the changes must start from the first stage of the cycle.
A
Waterfall Model
16
Q
Waterfall Model is best suitable when:
A
- Requirements are stable and clearly documented.
- Requirements are clear and complete, so there is no ambiguity.
- Static technology
- Short duration project
17
Q
Pros of Waterfall Model
- Easily understandable and simple to use.
- Managing each stage is simple as they have well-defined activities to follow, deliverables and reviews.
- Sequential stages and no overlapping keep the stage easy and manageable
- Milestones are clear.
- Documentation is strictly maintained so that the chances of dependencies are less.
- Small or mid-sized projects can easily adapt this model.
A
Cons of Waterfall Model
- Dependency on the previous stage to complete may cause delays.
- High maintenance cost
- Uncertainties and risks are very high.
- By the completion of the cycle, the software may be not competitive enough in the market to maintain the standards.
- Complex, long-term projects cannot rely on this model.
- Cannot handle change requests between the cycle is in progress.
18
Q
- This model is the one where the complete software is developed in multiple iterations, where the iteration follows Waterfall model.
- In each iteration, the subset of requirements is considered for development and they are integrated with the previous iteration.
- Tailoring the iterations leads to the software development in incremental way.
- Therefore, the Iterative model is sometimes referred to as “Iterative or Incremental Model”.
- It is basically developing the basic modules in the first iteration and then adding the other modules to it in the next iterations.
The main thing to focus here is to prioritize the modules that goes into different iterations. This usually is taken care in the design stage. This model ensures that each iteration undergoes rigorous validation of the developed requirements. Every cycle / iteration here will have the tests to repeat for the previous cycle / iteration and the tests for new modules added.
A
Iterative Model
19
Q
Iterative Model is applicable when:
A
- Final software’s requirements are well-defined.
- Large-sized projects
- Basic and main tasks are clear, and they may get enhanced later.
- Market constraints are well-known and by the time the software gets released it still be applicable.
- Scope for new technology to incorporate.
20
Q
Pros of Iterative Model
- Basic modules/functions can be developed first and then the remaining ones can be added in chunks.
- Supports parallel development.
- Measurable progress
- Easy to test and debug.
- Risks are easy to control and mitigate within the iteration.
- Each iteration is a lesson to improvise the process and eliminate the repetition of mistakes.
- Every iteration result in partial operational software
- Can incorporate the change requests in the next iterations.
- Customer evaluation and feedback is facilitated which enhances the quality of the software being developed.
- As the iterations have defined timelines, the project ending can be pre-determined and defined.
- Documentation effort is reduced, and design is focused.
A
Cons of Iterative Model
- Small-sized projects cannot adapt Iterative model.
- Management is the continuous activity to be handled.
- No scope for change in design
- Need of more resources and planning
- Risks cannot be determined for the later stages.
- Risk Management requires highly skilled resources.
- Large effort needed for rigorous validations when the code fixes are done at later iterations
- Usually, Documentation and Configuration Management are not followed strictly which leads to difficulties in tracing developed software back to the requirements
- Project management is not intensive which leads in deviating from formal processes to be followed
21
Q
- The combination of Waterfall and Iterative models leads to this model. This model is mainly to analyze the risks and to know when to move to the next stage. This Model works quite differently. There are four different phases in this model which are basically the predetermined time frames.
A
Spiral Model
22
Q
- The baseline here captures the business requirements. At the subsequent spirals, it enhances the identification of system, subsystem and unit requirements from the business requirements.
- It helps the software to mature in terms of clear, complete and concise requirements through continuous review process.
A
Determine Objectives, Alternatives, Constraints
23
Q
- This is the phase where the risks are identified and the measures to control and prevent them are defined.
- The risk analysis and planning to resolve them must be taken care by highly skilled professionals as this entire model mainly focuses on risk management.
- With subsequent spirals, the risk analysis grows stronger and can foresee the risks that may arise at the later stages.
A
Identify and Resolve Risks
24
Q
- At the baseline of the spiral, the Proof of Concept (POC) is developed, where the prototype and the likely design of the software is developed.
- The customer feedback is collected on the POC and then the actual work is started. The subsequent spirals encourage building the actual software with high clarity on requirements and design.
- Each of the software build is version numbered and tested against the requirements.
A
Develop and Test
25
* Upon collecting the customer feedback on the software build, plan the next iteration.
* This phase is to analyze and take the corrective measures in the next iteration to avoid schedule slippage and cost overrun.
* The plan is made ahead so that the movement to next stage happens on time even though the previous stage has not yet completed.
* The plan is derived out from the previous experiences, statistic data and the measures.
Plan the Next Iteration
26
Spiral Model is best adaptable when:
* Budget constraint
* Risk evaluation factor is high priority task.
* Long-term projects and requirements change over time.
* Requirements are not clearly known to customer himself
* Proof of Concept is needed
* Customer feedback is needed at the end of every spiral to adapt any changing requirements
* Requirements needs evaluation
27
Pros of Spiral Mode
* Facilitates early user involvement in the development process
* Changing requirements can be accommodated in well-defined manner
* Requirements can be evaluated for accuracy before staring the actual design
* Highly controlled Risk Management
* New features can be added at the later stages also
* Earlier working prototypes helps in collecting actual feedback on the software and enhance as per usability requirements
* High scalable
* Phase can be tweaked to finish it early if the risk is high at the next phase
Cons of Spiral Model
* Expensive and time consuming to reach final software
* Highly skilled professionals are required for risk management
* Poorer the risk-management, higher the project failure rate
* Not suitable for small, simple projects
* Documentation is more and time consuming
28
This model is the tweak to Waterfall model, where the development and testing activities go together. Instead of having the stages in linear way, this model takes the stages after implementation in the upward direction, forming the shape of alphabet “V”.
V Model
29
The Left side of V Model are all the Verification activities and right side are all the Validation activities
Requirement Analysis, Architecture, Design (Left)
Unit Testing, Integration Testing, System and Acceptance
Testing (Right)
30
1. During the requirements stage, the System and Acceptance test cases are identified and documented.
2. These Test Cases are executed during the System and Acceptance Testing Stage in development cycle.
3. During the Architecture stage, the Integration test cases are identified and documented. These Test Cases are executed during Integration testing stage in development cycle.
4. During the Design stage, the unit test cases are identified and documented by developers. These test cases are executed during the Unit testing stage in development cycle by developers.
Understanding the V-Model
31
V Model is best adaptable when:
* Requirements are clear and well-documented and stable
* Static technology and the project team is aware of the technology
* No ambiguity in requirements
* Short-term projects
* Highly-skilled professionals are needed
* Early-testing is required
32
Pros of V Model
* Early testing helps in identifying the defects at initial stages
* Requirement gaps can be identified very early
* Milestone can be reached sooner
* Short-term, small projects do not benefit from V Model
* Easy to control and manage as the stages are highly disciplined
Cons of V Model
* Rigid, lack of flexibility
* Complex and object-oriented projects cannot rely on V Model
* Ongoing projects do not benefit
* Changing requirements cannot be supported to higher extent
* Once the actual testing stage is reached, it is not very feasible to go back and change the functionalities
* Working software is not available until the end of life cycle
33
is the model which do not follow any process as such. The project starts with the set amount of money, time and resources. As and when the requirements start to come in, the development stage starts.
* The primary focus is coding and delivering the software. There is no planning or formal methods to follow in this model.
* Each module is validated at their level and when all the modules are ready individually, they are integrated at once.
* Any integration defects found, will be debugged at modules level by detaching them from the entire software.
Big Bang Model
34
Big Bang Model is suitable when:
* Customer is not sure on what is needed
* Small projects – school, enterprises, etc.
35
Pros of Big Bang Model
* Very simple model and easily understandable
* No formal planning or heavy processes
* Limited resources
* Provides flexibility to incorporate ideas while developing
* Managing is easy
Cons of Big Bang Model
* Not suitable for complex, object-oriented projects
* May become expensive at times
* Long term projects cannot rely on this model
* Involves many complexities throughout the project
36
This Methodology and Waterfall Approach are very different in nature. The way they handle the entire life cycle is completely different and have their own terms of benefits and drawbacks.
* is the methodology where the requirements, development and testing stages are all ongoing processes and the system analysts, developers, testers and customers all work together as a single team
* Here the releases are shorter, usually 6 – 8 weeks and each release has the timeframe called “Sprints” which is of 2 weeks (typically). Each sprint produces a work product.
Agile Model
37
* The collected requirements (user stories) are prioritized for the release and they are again prioritized for sprints. All the resources in the team work towards the identified user stories for the sprint.
* When the developers are coding the user stories, testers identify acceptance test cases, system test cases, regression test cases for the user stories.
* When the build is deployed, testers execute the identified test cases and reports defects and developers focus on fixing the defects and makes sure to close all the defects within the sprint itself. Once one sprint ends the next spring begins.
* This goes on in all the other sprints which keeps including new features and enhancements to the existing features.
* Customer interaction is very high in this methodology and the feedback and suggestions are collected at regular intervals to enhance the quality of the software.
Note
38
* Individuals and interactions are given more priority than processes.
* Working software is considered than heavy documentation of the software
* Customer collaboration is very extensive and the continuous feedback, suggestions and discussions helps in improving the software to meet user needs
* Respond to change in requirements dynamically. High priority requirements if coming in later stages, then the medium or low-level priority items are moved right to accommodate the high priority ones.
Principles of Agile:
39
Agile Methodology is best suitable when:
* Dynamic change in user requirements
* Early returns of Investment
* Low budget for changing requirements
40
Pros of Agile Model
* People oriented, more focus is on enhancing skill sets
* Minimum documentation saves time
* Supports dynamically changing requirements
* Helps in focusing on common goal
* High customer interaction improvises the quality continuously
* Highly flexible and realistic approach
* Early partial working software
* Less resources and equally distributed tasks
* Minimized risks
Cons of Agile Model
* Cannot finalize on the cost
* Client-oriented team
* Does not address dependencies
* Lack of detailed documentation causes challenging situation for the new members in the team
DevOps
flashcards
Decks in class (4)
# Cards
