PROCESS STEPS: 1. Requirement Analysis: Gathering information about what the customer needs and defining the problem that the product is expected to solve. The results of the analysis are typically captured in a formal requirements specification, which serves as input to the next step. 2. Design: It involves defining the hardware and software architecture. The output of this stage is one or more design specifications, which are used in the next stage of implementation. 3. Implementation: Constructing the product as per the design specification(s) developed in the previous step 4. Testing: In this stage, both individual components and the integrated whole are methodically verified to ensure that they are error-free and fully meet the requirements outlined in the first step. 5. Installation: This step occurs once the product has been tested and certified as fit for use, and involves preparing the system or product for installation 6. Maintenance: Involves making modifications to the system or an individual component to alter attributes or improve performance. These modifications arise either due to change requests initiated by the customer, or defects uncovered during live use of the system. PROCESS MODELS: 1. Waterfall: Staged development cycle enforces discipline. Progress can be conclusively identified. Emphasis on requirements and design. Lack of flexibility and room for error. No room to cater to changing needs. Model is used only when the requirements are very well known, clear and fixed. Product definition is stable. Bad for long and ongoing projects. 2. Agile: It’s open, flexible and suited for changing expectations. Follows an incremental development plan. Close communication. Ongoing testing throughout the process. Loose timelines can also make stakeholders nervous. Difficulty in agile methods is measuring success. Agile projects can suffer large impacts from mistaken architectural decisions. Lack of emphasis on necessary designing and documentation. 3. Iterative: After each iteration, the management team can do work on risk management and prepare for the next iteration. Because a cycle includes small portion of whole software process, it is easier to manage the development process but it consumes more resources. 4. V-Model: Provides means of testing of software at each stage in reverse manner. Makes both verification and validation go in parallel. Focuses on meeting the functionality specified in the requirements gathering. No early prototypes of the software are produced. Rigid and least flexible. Used for small to medium sized projects where requirements are clearly defined and fixed. 5. Spiral: High amount of risk analysis. Strong approval and documentation control. Risk analysis requires highly specific expertise. Costly. Good for large and mission-critical projects. Use when users are not sure of their needs.
Use all in different contexts. It’s all a matter of using the best fit for you and your project. The key to figuring out the right one for you is to clearly define stakeholder expectations and needs. Predictive approach: high criticality. Junior members. Large team. Stable. Order. MODELLING Helps us better understand the system we are developing. Models help us visualize a system as it is or as what we want it to be. Permit us to specify structure or behaviour of a system. Give us a template that guides us in constructing the system. Documents the decision that we made.
Correctness. Completeness. Consistency. Realism. Verifiability. Cost. Prioritization.
Validation = Dynamic Testing. Verification = Static Testing
How is the system doing a thing? Response Time, Resource Usage, Reliability, Failure Recovery, Maintainability, Modularity, Security, Usability, Extensibility, Reusability.May be more critical than functional requirements, if these are not met, the system is useless!