software process
the RUP is normally described from three perspectives
1-A dynamic perspective, which shows the phases of the model over time. 2. A static perspective, which shows the process activities that are enacted. 3. A practice perspective, which suggests good practices to be used during the process
faliure in the part of client to plan
A failure on the part of the client to plan and support the deployment of the system will impact on the performance of the system and its users and reworking of the 'deploy' phase.
error in creation f system
A mistake in the creation of the system designed to meet those needs will result in reworking of the 'design' activity.
error in requirement
An error in the software engineer's understanding of requirements will affect the ability to address the system user's needs and result in reworking of the 'specify' activity
spiral model 3
Development and validation After risk evaluation, a development model for the system is chosen. For example, throwaway prototyping may be the best development approach if user interface risks are dominant. If safety risks are the main consideration, development based on formal transformations may be the most appropriate process, and so on. If the main identified risk is sub-system integration, the waterfall model may be the best development model to use
Implementation and unit testing
During this stage, the software design is realized as a set of programs or program units. Unit testing involves verifying that each unit meets its specification.
During the final life cycle phase (operation and maintenance) the software is put into use
Errors and omissions in the original software requirements are discovered. Program and design errors emerge and the need for new functionality is identified
RUP Phases
Inception, Elaboration, Construction, Transition
Incremental development
Incremental development is based on the idea of developing an initial implementation, exposing this to user comment and evolving it through several versions until an adequate system has been developed
problems with incremental delivery 2
Iterative development can also be difficult when a replacement system is being developed. Users want all of the functionality of the old system and are often unwilling to experiment with an incomplete new system. Therefore, getting useful customer feedback is difficult
problems with incremental delivery 1
Most systems require a set of basic facilities that are used by different parts of the system. As requirements are not defined in detail until an increment is to be implemented, it can be hard to identify common facilities that are needed by all increments
incremental development
Once the system increments have been identified, the requirements for the services to be delivered in the first increment are defined in detail and that increment is developed. During development, further requirements analysis for later increments can take place but requirements changes for the current increment are not accepted
spiral model 4
Planning The project is reviewed and a decision made whether to continue with a further loop of the spiral. If it is decided to continue, plans are drawn up for the next phase of the project.
The Rational Unified Process
Provides a framework for breaking down the development of software into four gates
spiral model 2
Risk assessment and reduction For each of the identified project risks, a detailed analysis is carried out. Steps are taken to reduce the risk. For example, if there is a risk that the requirements are inappropriate, a prototype system may be developed.
RUP Construction
The construction phase involves system design, programming, and testing. Parts of the system are developed in parallel and integrated during this phase.
RUP Transition Phase
The final phase of the RUP is concerned with moving the system from the development community to the user community and making it work in a real environment
advantage of incremental development
The process maintains the benefits of incremental development in that it should be relatively easy to incorporate changes into the system
Software design and implementation
The process of converting the system specification into an executable system.
Software validation
The process of determining the degree to which software fulfills its intended purpose.
Software evolution
The software must evolve to meet changing customer needs.
Requirements analysis and definition
The system's services, constraints, and goals are established by consultation with system users. They are then defined in detail and serve as a system specification
System and software design
The systems design process allocates the requirements to either hardware or software systems by establishing an overall system architecture. Software design involves identifying and describing the fundamental software system abstractions and their relationships
Incremental development
This approach interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with each version adding functionality to the previous version.
Reuse-oriented software engineering
This approach is based on the existence of a significant number of reusable components. The system development process focuses on integrating these components into a system rather than developing them from scratch
Milestones
a 'Preliminary Software Review' (PSR) between supplier and customer before formally moving on to the analysis phase, based on a preliminary program design which acts as a form of prototype to guide design and coding. As work develops, 'Critical Software Reviews' (CSRs) can be scheduled with the customer, to further inform the coding process. Finally, the transition from testing to operational deployment is controlled by a 'Final Software Acceptance Review' (FSAR) between the testing and operations phases
Spiral Model
a metaphor used to describe the tendency of efforts to enhance defense to result in escalating arms races
spiral model
a metaphor used to describe the tendency of efforts to enhance defense to result in escalating arms races
different software processes
four activities that are fundamental to software engineering
RUP Elaboration Phase
he goals of the elaboration phase are to develop an understanding of the problem domain, establish an architectural framework for the system, develop the project plan, and identify key project risks
Software processes can be improved by process standardization where the diversity in software processes across an organization is reduced.
his leads to improved communication and a reduction in training time, and makes automated process support more economical. Standardization is also an important first step in introducing new software engineering methods and techniques and good software engineering practice
software process
is a set of related activities that leads to the production of a software product
Pre- and post-conditions
statements that are true before and after a process activity has been enacted or a product produced
what are innermost loop in spiral model
the innermost loop might be concerned with system feasibility, the next loop with requirements definition, the next loop with system design, and so on. The spiral model combines change avoidance with change tolerance
the waterfall model should only be used when
the requirements are well understood and unlikely to change radically during system development. However, the waterfall model reflects the type of process used in other engineering projects.
documentation of process
the result of each phase is one or more documents that are approved ('signed off').
Incremental development
A program development plan intended to avoid debugging by adding and testing only a small amount of code at a time.
Boehm's spiral model
A risk-driven software process framework (the spiral model)
Waterfall Model
A series of steps in which a software system trickles down from analysis to design to implementation.
Incremental delivery has a number of advantages
Customers can use the early increments as prototypes and gain experience that informs their requirements for later system increments. Unlike prototypes, these are part of the real system so there is no re-learning when the complete system is available
advantage of incremental development 1
Customers do not have to wait until the entire system is delivered before they can gain value from it. The first increment satisfies their most critical requirements so they can use the software immediately.
Operation and maintenance
Normally (although not necessarily), this is the longest life cycle phase. The system is installed and put into practical use. Maintenance involves correcting errors which were not discovered in earlier stages of the life cycle, improving the implementation of system units and enhancing the system's services as new requirements are discovered.
spiral model sector 1
Objective setting Specific objectives for that phase of the project are defined. Constraints on the process and the product are identified and a detailed management plan is drawn up. Project risks are identified. Alternative strategies, depending on these risks, may be planned
problems with incremental delivery 3
The essence of iterative processes is that the specification is developed in conjunction with the software. However, this conflicts with the procurement model of many organizations, where the complete system specification is part of the system development contract. In the incremental approach, there is no complete system specification until the final increment is specified. This requires a new form of contract, which large customers such as government agencies may find difficult to accommodate.
Software specification
The functionality of the software and constraints on its operation must be defined
milestone goals
The goal is to minimise the wasted work that results from re-iteration of previous phases. The PSR, CSR and FSAR are not simply reviews of what has happened already, they prevent problems being fed forward into the next phase. In this respect, they are akin to quality gates or milestones. The reviews have a significant effect on the way phases are re-iterated
RUP Inception
The goal of the inception phase is to establish a business case for the system. You should identify all external entities (people and systems) that will interact with the system and define these interactions. You then use this information to assess the contribution that the system makes to the business. If this contribution is minor, then the project may be cancelled after this phase.
Integration and system testing
The individual program units or programs are integrated and tested as a complete system to ensure that the software requirements have been met. After testing, the software system is delivered to the customer
the main difference spiral model and other
The main difference between the spiral model and other software process models is its explicit recognition of risk. A cycle of the spiral begins by elaborating objectives such as performance and functionality
The waterfall model
The most popular model. In this cycle, each phase must be completely finished before the next begins
The waterfall model
The waterfall model is an example of a plan-driven process—in principle, you must plan and schedule all of the process activities before starting work on them
The waterfall model
This takes the fundamental process activities of specification, development, validation, and evolution and represents them as separate process phases such as requirements specification, software design, implementation, testing, and so on
Spiral Model
the software process is represented as a spiral, rather than a sequence of activities with some backtracking from one activity to another
V-Modell
the waterfall testing phase and sub-divides it in accordance with the V-Modell approach to verification and validation.
software process model
an abstract representation of a process. It presents a description of a process from some particular perspective.
The development of a bespoke software system can be thought of as a process with three 'actors':
• A system user, whose requirements determine the intended scope and behaviour of the system. • A team of system engineers who translate that specification into a design for the system. • The system created from that design.
