The Process Infsy 570 Dr. R. Ocker

Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

The Process n software process –framework for the tasks that are required to build high-quality software n Quality - basic notion behind SWE

some SWE definitions n the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines n (1) the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. n (2) the study of approaches used in (1).

Process, Methods, and Tools

SWE Process n glue that holds everything together; supposed to enable rational and timely development of SW n process defines the framework that must be followed for sw delivery n used for management control n establish the context in which technical methods are applied, etc.

SWE Methods n provide the technical how to’s for building sw; n methods encompass tasks, including: n requirements analysis n design n program construction n testing n maintenance

SWE Tools n provide automated support for the process and methods n CASE - when tools are integrated so that information created by one tool can e used by another

Generic view of SWE n engineering is the analysis, design, construction, verification, and management of technical entities.

3 generic phases of SWE: n definition n development n maintenance

1.definition phase - focus on what n what information is to be processed n what function and performance are desired n what system behavior can be expected n what interfaces are needed n what design constraints exist n what validation criteria are required to define a successful system

3 tasks occur n 1.system or information engineering n 2.software project planning n 3.requirements analysis

2.development phase - focus on how n how data are to be structured n how function is to be implemented n how interfaces are to be characterized n how design will be translated into programming languages n how testing will be performed

3 specific technical tasks always occur n 1.software design n 2.code generation n 3.software testing

3.maintenance phase - focus on change n error correction n adaptations required as SW evolves n changes due to enhancements brought about by changing customer requirements

Umbrella activities n applied throughout the sw process; include: –project tracking and control –formal technical reviews –quality assurance –configuration management –document preparation and production –measurement –risk management

SW Process n emphasis on process maturity n Software Engineering Institute (SEI) developed comprehensive model based upon a set of SWE capabilities that should be present as organizations reach different levels of process maturity

capability maturity model n defines key activities required at different levels of process maturity n 5 process maturity levels

level 1 - initial n sw process is ad hoc, maybe even chaotic n few processes are defined n success depends on individual effort

level 2 - repeatable n basic project management processes are established to track cost, schedule, and functionality n Necessary process discipline is in place to repeat earlier successes on projects with similar applications

level 3 - defined n sw process for both management and engineering activities is documented, standardized, and integrated into an organization-wide sw process n all projects use a documented and approved version the this for developing and maintaining sw

level 4 - managed n detailed measures of sw process and product quality are collected n both sw process and products are quantitatively understood and controlled using detailed measures

level 5 - optimizing n continuos process improvement is enabled by quantitative feedback from the process and from testing innovative ideas and technologies.

Software Process Models n Process models differ from a sw method/methodology n method’s primary focus is on: –how to navigate through each phase e.g. partitioning functions –how to represent the products of each phase e.g. structure charts n software process models specify the order in which a project should carry out its major tasks

We will look at: n code-and-fix model n linear sequential model (life cycle) n prototyping model n human factors approach*** n RAD model n Evolutionary process models (iterative) –incremental model –Spiral model*****

A.Code-and-Fix Model (2 steps) n 1.Write some code n 2.Fix the problem in the code n earliest process model n problems: spaghetti code, lack of planning, difficult to maintain over time, no requirements phase

B.Linear Sequential/ Stagewise/Life Cycle and Waterfall Models (fig. 1, Boehm88) n software developed in successive stages (linear sequential) n Waterfall - added feedback loops between stages n followed code-and-fix model n traditional approach to development n not iterative but sequential stages n deliverables and milestones at each stage

basic stages: n analysis n design n coding n testing n maintenance

Advantages: n designed for control n complete system delivered after linear sequence completed

Disadvantages: n emphasis on document driven standards (e.g. fully elaborated documents as completion criteria for early requirements and design phases); n can result in elaborate specs. of poorly understood user interfaces followed by design and development of large quantities of unusable code

C.Prototyping Model n designed to help understand requirements n build an experimental system rapidly and inexpensively for users to evaluate

2 types of prototypes: n 1. evolutionary n prototype evolves into working system n 2. throw away n after prototype completed and requirements determined, it is “thrown away” n software developed beginning with design stage

iterative process of development (fig. 1 Alavi84) n 1.identify initial user requirements n 2.develop prototype n 3.use & evaluate prototype n 4.revise prototype (back to 3)

prototyping n prototyping much more iterative than SDLC n promotes design changes n less formal approach than SDLC n quickly generate working model of system

Advantages of prototyping: n useful when uncertainty about information requirements or design solutions n good for design of user interface n encourages user involvement throughout development

Disadvantages: n no detailed specifications - should not substitute for careful requirements analysis n better suited for smaller applications n more difficult to control than SDLC - must plan the effort in advance to control for cost, effort, and time limits n be prepared for more changes than in SDLC

D.Human Factors (Mantei & Teory, 1988) n incorporates changes into prototyping process model based on human factors engineering

prototyping lifecycle (fig. 1) n fits prototyping into linear sequential (life cycle) process model –feasibility study –requirements definition –global design –prototype construction –user evaluation –system implementation –testing –update and maintenance

fig. 2 add human factors to life cycle n market analysis n feasibility study n requirements definition n product acceptance analysis n task analysis n global design n prototype construction

fig. 2 (cont.) add human factors to life cycle n user testing and evaluation n user evaluation n system implementation n product testing n user testing n update and maintenance n product survey

Human Factors aspects: n MARKET ANALYSIS (iterative) * - Run “focus groups” with users to determine their perceptions and needs n PRODUCT ACCEPTANCE ANALYSIS * - Prepare a system “mockup” for presentation to a sample of users (changes can be recommended at this point). These changes result in a loop back to the requirements definition stage.

Human Factors aspects: n TASK ANALYSIS * - Examines the users’ mental process relative to the procedures currently being used. The results are employed in the global design and prototype construction stages in “tuning” the user interface to reflect their thought process.

Human Factors aspects: n USER TESTING AND EVALUATION * - finished prototype presented to sample of users for testing (ease of use, functionality and performance). n Resultant design changes require looping back through the global design and prototype construction stages. n Major system failings call for revisiting the requirements definition stage.

Human Factors aspects: n USER TESTING * - Upon completion of “user testing and evaluation”, the system is implemented and undergoes traditional product testing (unit and system) by the developers. The system is now subjected to a second round of USER testing.

Human Factors aspects: n PRODUCT SURVEY * -obtain more user feedback n This stage is tied to the ongoing update and maintenance process. –Small changes handled by looping back to requirements determination stage. –significant revisions may require going all the way back to “market analysis”, for a complete re-evaluation.

Other Considerations: n Cost effectiveness increases with the number of users n Savings from running user studies also rise with user population n Rule of thumb - use a prototype when the cost is less than 25% of the total project cost n Human factors model not recommended for small/simple projects, better suited to large user base or complex systems

Good example... n NOTE:This article provides a great example of applying numbers (benefits and costs) to SWE.

E.RAD Model n linear sequential process n emphasizes very short development cycle (60-90 days) n use when requirements are well- understood and project is scaleable (able to break into concurrent pieces) n each major function developed by a separate RAD team n emphasizes reuse

RAD phases: n 1.business modeling n look at information flow among business processes n 2.data modeling n data objects to support the business n 3.process modeling n create process descriptions to support business functions

RAD phases: n 4.application generation n 4th generation languages, reuse existing programs n 5.testing & turnover n test new components only

F.Evolutionary Process Model n stages consist of expanding increments of an operational software product (iterative development) n 1.Incremental model n 2.Spiral model

1.Incremental Model n turns linear sequential approach (analysis, design, code, test) into iterative approach n system broken down into series of pieces or iterations n stagger sequences over time n each linear sequence produces a deliverable increment of the system

1.Incremental Model n first increment = core system; covers basic reqs. n good to use when staffing not adequate to deliver complete system n also use increments to manage risk

Advantages: n matched to fourth generation languages application n good fit when users say, “I can’t tell you what I want, but I’ll know it when I see it”

Disadvantages: n difficult to distinguish from the old code- and-fix model (spaghetti code, lack of planning); n assumes that system can accommodate uplanned evolution plans

2.Spiral Model (figure 2, Boehm88) n sw developed in series of incremental releases n model uses concept that each cycle involves a progression that addresses the same sequence of steps, from an overall concept of operation document to the coding of each individual program.

Typical Spiral Cycle: n Determine objectives, alternatives, constraints –determine objectives for portion of product being elaborated –identify alternatives to implement it –identify constraints imposed on alternatives

Typical Spiral Cycle: n Evaluate alternative, identify, resolve risks n evaluate alternatives relative to objectives and constraints n identify uncertainties that are significant sources of project risk n formulate strategy to resolve risks (may involve prototyping, simulation, benchmarking, user surveys, etc.)

Typical Spiral Cycle: n Develop, verify next-level product n e.g. generate sw requirements and perform requirements validation n Plan next phases n e.g. development plan; integration and test plan

Spiral Model Template n Each round of the spiral model addresses the following: –Objective –Constraints –Alternatives –Risks –Risk Resolution –Risk Resolution Results –Plan for Next Phase –Commitment

Evaluation: n Primary Advantage of Spiral Model: n its range of options accommodates the good features of existing software process models, while its risk-driven approach avoids many of their difficulties

Other Advantages: n it focuses early attention on options involving the reuse of existing software n it accommodates preparation for life- cycle evolution, growth, and changes of the software product n it provides a mechanism for incorporating software quality objectives into software product development n it focuses on eliminating errors and unattractive alternatives early n it answers the question “How much is enough?” n it doesn’t involve separate approaches for software development and software enhancement n it provides a viable framework for integrated hardware-software system development

Other Advantages: n focuses on early elimination of errors n answers the question “How much is enough?” n doesn’t involve separate approaches for software development and software enhancement n provides a viable framework for integrated hardware-software system development

Difficulties: n matching to contract software n relying on risk-assessment expertise n need for further elaboration of spiral model steps

Risk Management Plan n one characteristic of spiral approach that can be adapted to life-cycle models n ensures that each project makes an early identification of top risk items and develops a strategy for resolving risks

Unit Review:Process Model Comparison n Create a chart describing all of the above process models (including both evolutionary models).

Unit Review:Process Model Comparison n On this chart, complete the following categories: –basic description of process –steps in process –unique features of process –advantages of using process –disadvantages of using process –when to use process