Software Processes, Slides of Software Engineering

Download Software Processes and more Slides Software Engineering in PDF only on Docsity!

CHAPTER 2 – SOFTWARE

PROCESSES

SE 200 – SOFTWARE ENGINEERING

TOPICS COVERED

◼ Software process models ◼ Process activities ◼ Coping with change (Change management) ◼ Process improvement

SOFTWARE PROCESS DESCRIPTIONS

◼ When we describe and discuss processes, we usually talk about the activities in these processes such as specifying a data model, designing a user interface, etc. and the ordering of these activities. ◼ When describing processes, it is also important to describe^ who^ is involved, what is produced, and conditions that influence the sequence of activities ◼ Process descriptions may include: ◼ Products, which are the outcomes of a process activity; ◼ Roles, which reflect the responsibilities of the people involved in the process; ◼ Pre- and post-conditions, which are statements that are true before and after a process activity has been enacted or a product produced.

PLAN-DRIVEN AND AGILE PROCESSES

◼ As there is^ no universal process that is right for all kinds of software , most software companies have developed their own ◼ Plan-driven processes^ are processes where all of the process activities are planned in advance and progress is measured against this plan. ◼ In agile processes , planning is incremental and it is easier to change the process to reflect changing customer requirements. ◼ In practice, most practical processes include elements of both plan-driven and agile approaches. ◼ There are no right or wrong software processes, there is scope for process improvement in many organizations.

SOFTWARE PROCESS MODELS / SDLC

◼ The waterfall model ◼ Plan-driven model. Separate and distinct phases of specification and development such as requirements specification, software design, implementation, and testing. ◼ Incremental development ◼ Specification, development and validation are interleaved. May be plan-driven or agile. The system is developed as a series of versions (increments), with each version adding functionality to the previous version. ◼ Integration and configuration ◼ The system is assembled from existing configurable components. May be plan- driven or agile. The system development process focuses on configuring these components for use in a new setting and integrating them into a system. In practice, most large systems are developed using a process that incorporates elements from all of these models. RUP (Rational Unified Process)

THE WATERFALL MODEL

WATERFALL – TYPE OF SYSTEMS

◼ Embedded systems^ - where the software has to interface with hardware systems. Because of the inflexibility of hardware, it is not usually possible to delay decisions on the software’s functionality until it is being implemented. ◼ Critical systems^ - where there is a need for extensive safety and security analysis of the software specification and design. In these systems, the specification and design documents must be complete so that this analysis is possible. Safety related problems in the specification and design are usually very expensive to correct at the implementation stage. ◼ Large software systems^ - that are part of broader engineering systems developed by several partner companies. The hardware in the systems may be developed using a similar model, and companies find it easier to use a common model for hardware and software. Furthermore, where several companies are involved, complete specifications may be needed to allow for the independent development of different subsystems.

WATERFALL MODEL PROBLEMS

◼ Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. ◼ Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process. ◼ Few business systems have stable requirements. ◼ The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites. ◼ In those circumstances, the plan-driven nature of the waterfall model helps coordinate the work.

INCREMENTAL DEVELOPMENT BENEFITS

◼ The cost of accommodating changing customer requirements is reduced. ◼ The amount of analysis and documentation that has to be redone is much less than is required with the waterfall model. ◼ It is easier to get customer feedback on the development work that has been done. ◼ Customers can comment on demonstrations of the software and see how much has been implemented. ◼ More rapid delivery and deployment of useful software to the customer is possible. ◼ Customers are able to use and gain value from the software earlier than is possible with a waterfall process.

INCREMENTAL DEVELOPMENT PROBLEMS

◼ The process is not visible. ◼ Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system. ◼ System structure tends to degrade as new increments are added_._ ◼ Unless time and money is spent on refactoring to improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly difficult and costly.

TYPES OF REUSABLE SOFTWARE

◼ Stand-alone application systems^ (sometimes called COTS) that are configured for use in a particular environment. ◼ Collections of objects^ that are developed as a package to be integrated with a component framework such as .NET or J2EE. ◼ Web services^ that are developed according to service standards and which are available for remote invocation.

REUSE-ORIENTED SOFTWARE

ENGINEERING

ADVANTAGES AND DISADVANTAGES

◼ Reduced costs and risks as less software is developed from scratch ◼ Faster delivery and deployment of system ◼ But requirements compromises are inevitable so system may not meet real needs of users ◼ Loss of control over evolution of reused system elements

PROCESS ACTIVITIES