Software Engineering, Chapter 2

Inception

Establishbusiness rationale for project Decideproject scope Identifyactors and use cases Work Products(artifacts):oVision document o Initial use-case modeloInitial risk assessment o Project plan o Prototype

Software life cycle

When a process involves building a software, the process may be referred to as software life cycle oRequirements analysis and definition oSystem (architecture) design oProgram (detailed/procedural) design oWriting programs (coding/implementation) oTesting: unit, integration, system oSystem delivery (deployment) oMaintenance

Unified Process Phases

1) Inception 2) Elaboration 3) Construction 4) Transition

Plan-Driven Software Process Models

1.Code-and-fix model 2.Waterfall model 3.Incremental model 4.Rapid prototyping model 5.Iterative model 6.Unified Process model 7.Component-Based model In practice, most large systems are developed using a process that incorporates elements from all of these models.

Process

A process: a series of steps involving activities, constrains, and resources that produce an intended ouput of some kindA process involves a set of tools and techniques

Miller's Law

At any one time, we can concentrate on only approximately seven chunks(units of information) To handle larger amounts of information, use stepwise refinement oConcentrate on the aspects that are currently the most importantoPostpone aspects that are currently less critical oEvery aspect is eventually handled, but in order of current importance This is an incrementalprocess

Component based development

Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems. Process stagesoComponent analysisoRequirements modificationoSystem design with reuseoDevelopment and integration Reuse is now the standard approach for building many types of business system The followings are examples of component standards which have their own component libraries and consistent structures. o OMG / CORBA o Microsoft COM o Sun JavaBeans Pros system reliability is increased (standard reusable components should be well tested and perhaps formally verified) development time is reduced odesign and coding time is reduced otesting time is reduced standards can be implemented as reusable components ostandards for fault-tolerance or correctness ostandards for user interfaces•a company's "look and feel" could come from reuse of standard user interface components Cons reusing components leads to changes in design and requirements developers always believe they could develop better components anyway incorporating component libraries often leads to larger and less efficient implementations organizations are reluctant to expend resources ($$) to develop reusable components no standard way to catalog and search for reusable components no guarantee that reusing components leads to faster development or more reliable systems new versions of purchased components are not controlled by the development organization, which may affect system

Transition

Beta-test Tune performance Train users Work Products: o Delivered software increment o Beta test results o General user feedback

Construction

Build, test and validate the project Work Products: o Designmodel o Software components o Test plan and test cases o Support documenatation User manuals Installation manuals Description of current increment

Elaboration

Collect more detailed requirements Do high-level analysis and design Establish baseline architecture Create construction plan Work Products:oUse-case model o Non-functional requirements o Analysis model o Software architecture description o Preliminary design model o Preliminary user manual

Rapid Prototyping Model:

Prototyping is used for:ounderstanding the requirements for the user interfaceocan start with initial requirements to clarify what is really neededoexamining feasibility of a proposed design approachoexploring system performance issues Preferred for new technologyprojects. A prototype has only a limited capability. Mostly prototyping takes 3-4 months. May be based on rapid prototyping languages or tools May involve leaving out functionality o Prototype should focus on areas of the product that are not well-understood; o Error checking and recovery may not be included in the prototype; o Focus on functional rather than non-functional requirements such as reliability and security Prototypes should be discarded after development as they are not a good basis for a production system:oIt may be impossible to tune the system to meet non-functional requirements; o Prototypes are normally undocumented; o The prototype structure is usually degraded through rapid change; o The prototype probably will not meet normal organizational quality standards. Pros Improved system usability. A closer match to users' real needs. Improved design quality. Improved maintainability. Reduced development effort. Cons Usually the customer insists on «small modifications» to prototype system after seeing sth appears to be a working version of the software. The developer may use inappropriate components for building prototype quickly. By time, they get comfortable with the choices and forget all reasons why ther were inappropriate. Less-then-ideal choices become a part of the system.

Reasons of modeling a process

To form a common understanding To find inconsistencies, redundancies, omissions To find and evaluate appropriate activities for reaching process goals To tailor a general process for a particular situation in which it will be used

The Unified Process

The Unified Process (UP) is a"use-case driven, iterative and incremental" software process model closely aligned with Object-Oriented Analysis and Design. A modern generic process derived from the work on the UML and associated process. Brings together aspects of the 3 generic process models discussed previously. Normally described from 3 perspectivesoA dynamic perspective that shows phases over time; o A static perspective that shows process activities; o A practive perspective that suggests good practice. Each phase ends at a major milestone and contains one or moreiterations. An iteration is a distinct sequence of activities with anestablished plan and evaluation criteria, resulting in anexecutable release.

Code-Fix

The easiest way to develop software No design, no specifications Maintenance extremely difficult The most expensive way Typically used by a start-up

Spiral Model

The spiral model is a software development process combining the elements of both design and prototyping-in-stages. This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive and complicated projects. Process is represented as a spiral rather than as a sequence of activities with backtracking. Each loop in the spiral represents a phase in the process. No fixed phases such as specification or design -loops in the spiral are chosen depending on what is required. Risks are explicitly assessed and resolved throughout the process. Spiral Model Sectors: Objective setting o Specific objectives for the phase are identified. Risk assessment and reduction o Risks are assessed and activities put in place to reduce the key risks. Development and validation o A development model for the system is chosen which can be any of the generic models. Planning o The project is reviewed and the next phase of the spiral is planned.

Iterative- Incremental model

•Avoids "big bang"implementation •Assumesall requirements known up-front •Each release adds more functionality •Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve. Pros The cost of accommodating changing customer requirements is reduced. oThe 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. oCustomers 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. oCustomers are able to use and gain value from the software earlier than is possible with a waterfall process. Cons The process is not visible. oManagers 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. oUnless 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.

Waterfall Model

•Separate and distinct phases •Feedbackloops •Documentation-driven Pros: Simple and disciplined, structured approach Project Management is easy Maintenance is easier Cons: Difficulty of accommodating change after the process is underway. Necessitates stable requirement oFew business systems have stable requirements •Military, Government Projects Major design problems may not be detected till very late Very late delivery Blocking phases o Coders must wait designers to