2. What is a life cycle model?
Framework under which a software product is going to be developed.
Defines the phases that the product under development will go through.
Identifies activities involved in each of the phases and their respective deliverables.
Efforts of various stakeholders from industry and academia.
A successful model: adopted by the software industry and has undergone many modifications and enhancements to improve its efficiency and applicability.

3. Pre-development activities
Prior to embarking into the activities and the phases of the software life cycle development model, there are some pre-development activities and deliverables that must be performed to enable the proper startup of the software development project.

4. Predevelopment activities
Extent of the pre-development activities depend on the complexity and type of software to develop.
For a software system to be implemented as a part of a complete system including software, hardware and people, the allocation of functions to the software component of the system and the interactions and boundaries between the software and other system elements must be clearly identified.

6. What is a life cycle model?
An ideal life cycle model is generic, flexible, adaptable and scalable.
To be tailored to suit the particular needs of the company and its development team.
flexible to allow different emphasis on different phases, activities and deliverables
Must scale up to large and complex software systems development projects.

7. What is a life cycle model?
Many industrial-strength and popular models have been used to develop software products of different complexities and in a wide variety of application domains.
waterfall or system development life cycle model, the prototyping model, the spiral model, the object-oriented model, the incremental and iterative model, the extreme model, and the component based model.

10. Software maintenance activities
Software maintenance activities include;
the management of software improvement requests,
the identification, categorization and prioritization of needed improvements, and
the scheduling and execution of the needed improvements.
The management of requests is facilitated using a user friendly system for requesting software improvements and reporting software faults.
This system is used by software users, software developers and the client to report software faults and to request enhancements to the software.
Requests and error reports are then analyzed by the maintenance team.
The scheduling of the execution of requests depends mainly on their complexity and urgency.

11. Types of maintenance activities
Corrective maintenance activities are triggered by software faults encountered during the use of the software. They involve simple fixes like cosmetic changes to the user interface, or more complex fixes like redesign of a module or the re-introduction of a missing functionality.
Preventive maintenance activities involve dealing with weaknesses and vulnerabilities identified by the development team during or after deploying the software and were not dealt with in the installed software.

12. Software maintenance activities
Perfective maintenance activities involve dealing with requests to improve the efficiency of the algorithms and data structures, and user interface interactions used in the design.
Adaptive maintenance activities involve requests from software stakeholders to adapt the software to different operating environments, user interface styles, social contexts, or even new government regulations and standards.

13. Ongoing (umbrella) activities
Project management
Quality assurance
Evaluation and testing
Configuration management
Technical support
Internal training
Documentation
Operations support and user training

14. Project management
Project manager continuously performs project management related activities.
Progress of the activities is closely monitored using an appropriate reporting procedure.
Risks are continuously monitored and corrective actions are taken when needed. New risks are identified and monitored.
The project schedule is updated regularly if needed.
Project and process related metrics are regularly collected.
Regular human resource management and project management activities including delegation and evaluation are performed.

15. Quality assurance
During and at the end of each phase, QA group reviews the phase deliverables and ensures the use of and conformance to internal and external standards.
Reviews of parts of the deliverables are conducted during the phase execution and after the deliverables are produced.
Quality reports and logs are maintained and relevant metrics are collected according to the metrics collection plan.
The quality assurance plan is executed and updated if needed.
Process improvement recommendations are also provided by the group after completion of the project.

16. Evaluation and testing
Validation and verification activities
At the end of each phase, deliverables are evaluated and tested.
Once deliverables are approved, the next phase will start.
Formal and informal processes can be used for evaluation and testing purposes.
performed by the developers and by independent groups like the QA group.
Informal evaluation processes include reviews
walkthroughs, inspections, and audits.

17. Evaluation and testing (2)
Formal evaluation processes include the use of formal techniques and automated tools for the verification of phase deliverables.
Tools and techniques for design verification and code testing can be used for these purposes.
Formal product validation techniques can also be used to generate and document effective tests, to automate the validation process and to analyze validation results.

18. Configuration management
CM deals mainly with the management of the software resources and the overall support and control of the software development and maintenance processes.
CM activities include:
the identification of all software documents, deliverables and artifacts that will be produced, manipulated and maintained during the development and maintenance of the software.
CM control activities include revision and version control, process and workflow control, build control and change control.
Performed using an integrated and automated configuration management tool for revision, version, build and change management.
Periodic CM audit and status report is generated and analyzed by the management team.

19. Technical support and internal training
Developers may require some technical support and training.
Support technicians help the developers in solving technical problems that may arise while developing the software.
These activities help improve the efficiency and productivity of the development and maintenance teams.
A training plan can be devised as part of a project plan to deal with the training of technical staff on the development process, standards to be followed, or new tools and technologies that will be used.

20. Documentation Documents targeting different audiences are produced.
internal and technical documents that are needed for future software maintenance activities.
documents target external users and include user, installation and operations manuals.
Standards and standard templates are used to guide the writing of these software related documents.
Technical writers are normally involved with the production of the external documents.
Documents are evaluated by internal review processes involving various stakeholders including software development team members and QA group.

21. Operations support and user training
After installing the software, its operations is supported by providing customer help desk support, technical assistance, user training and consulting.
Help desk request logs and fault report logs are maintained and appropriate metrics are generated.
Fault reports are used to trigger the appropriate maintenance and process improvement activities.

24. Prototyped waterfall model
Allows visualization of requirements
Find out requirements errors earlier
Better quality – user interface
Interactive with client / user
Easy and quick to build prototype
Prototype to throw away – do not use it to continue building the software
Use programming language other than the one to be used to develop the software
Visual Basic

26. Object oriented model Object oriented
Analysis – Identification of problem domain objects, object attributes and methods (operations), object relationships: aggregation (composition), inheritance and communication, scenarios using sequences of interactions
Design – solution domain classes and interrelationships, entity, interface and control classes.
Implementation – use Java, C++, C#
Use the Unified Modeling Language (UML)

27. Incremental and iterative model
Prioritizing requirements
Identify requirements for different releases
Use a model to develop each release

29. Spiral model Introduced by Barry Boehm in 1988.
Model addresses the weaknesses of the waterfall model with respect to the treatment of software development risks.
Model embeds risk management activities within the development activities.
Software risks and the lack of a clear and continuous risk management strategy are the main reason for software project failures.
Continuous consideration of risks embedded within the software development process would contribute to enhancing the quality of software.

30. Spiral model (2)
Each cycle in the spiral model involves the repeated execution of 4 steps at each phase
Identification of objectives, alternatives and constraints that are relevant at that phase
Evaluation and assessment of the alternatives with respect to constraints and identified potential risks
Develop the phase deliverable by performing its activities, followed by a review of these deliverables.
Preparation and planning for the following phase:
may prescribe the partitioning of the remaining work into different sequential or parallel software increments, leading to concurrent spiral model execution of the remaining phases.

32. Rational unified process (RUP)
Process management tool encapsulating best practices in software development and maintenance:
iterative and incremental development of software, requirements management, software components reuse, visual modeling, software quality verification, and configuration and change management.
RUP is a configurable product
can be adapted to software products of different types and complexities.
RUP consists of sequential phases for the iterative development of software:
inception, elaboration, construction and transition

33. [you can use the original drawing from the web]

34. Inception phase
Team develops business context and project scope of the project.
Product stakeholders are indentified and their interfaces with the software to develop are determined.
All use cases are identified and partly developed and prototyped. A risk management plan, and cost and schedule estimations are developed.
Deliverables include a vision and scope document, an initial use case model, an initial project plan including a risk management plan and an initial prototype.
Financial and technical feasibilities of the project are carefully assessed at this point and a go / no go decision is made.

35. Elaboration phase
Use case model is formalized and an executable prototype of the most complex and critical use cases is implemented.
Deliverables include a use case model, non-functional requirements specifications, a revised and complete project plan including revised risk management plan and more accurate estimates of cost and time needed to complete the project, and an executable prototype.
Inception and elaboration phases of RUP correspond to the software requirements specification or analysis phase of the prototyped waterfall model.

36. Construction phase
Software is designed, implemented and integrated prior to its deployment in the transition phase.
Various software releases may be constructed concurrently to accelerate the deployment of high priority features of the software product.
Deliverables include the software design document, the software product and all related documentation including installation and user manuals.

37. Transition phase
Software product is deployed and made available for use by its intended user population.
The product is validated against the requirements.
Necessary database conversions are performed.
Training of software users and operators is provided.
Product is distributed to its intended users using the appropriate distribution channels.

38. RUP activities
RUP can also be described by its activities that are clustered into different workflows.
Each workflow culminates in one or more deliverable.
9 workflows are identified:
business modeling, requirements, analysis and design, implementation, test, deployment, project management, configuration and change management, and environment.
Activities of one workflow may span more than 1 phase.
Project management, change / configuration management and environment activities are spread over the 4 phases of the RUP.
These three workflows are called core supporting workflows.
The other 6 workflows are called core process workflows.

39. Software development and maintenance teams
Possible team structures
Functional
Project
Hybrid functional / project
Each has its advantages and disadvantages

42. Software engineering standards

44. Capability maturity model (CMM)
CMM was developed by W. Humphrey at the SEI at CMU for the assessment of the development processes at software development companies.
CMM Integration (CMMI) assists in the assessment of the process maturity in areas like systems engineering, project management, and supply-chain management.
CMM does not recommend any particular set of mature processes to be followed by an organization.
CMM can be used to assess the maturity of existing processes. The basis for the placement at a particular level is based on the availability of specific process areas defined for that level.
As a result of the process maturity assessment, an organization is placed at one of 5 maturity levels: initial, repeatable, defined, managed and optimized.

46. Unified Modeling Language (UML)
Joint efforts by object-oriented methodologists
De facto standard language for software modeling
Visual language for modeling software systems from many aspects and views
Modeling software structure, behavior and architecture