1. Statement of Work Lecture

2. SOW The statement of work is the basis of the contract between the pro- poser and the customer, and is often incorporated into the contract. The SOW contains a detailed list of all work to be performed by the service provider for the benefit of the customer. It is a narrative description of products or services to be supplied by the project.

3. For internal projects, the project initiator or sponsor provides the statement of work based on business needs, or product or service requirements. For external projects, the statement of work can be received from the customer as part of a contract document / bid document, for example, request for proposal, request for information, request for bid, or as part of a contract

4. The SOW indicates : Business need an organization’s business need, can be based on needed training, market demand, technological advance, legal requirement, or governmental standard. Product scope description Documents the product requirements and characteristics of the product or service that the project will be undertaken to create. The product requirements will generally have less detail during the initiation process and more detail during later processes

5. The SOW indicates : Strategic plan all projects support the organization’s strategic goals—the strategic plan of the performing organization should be considered as a factor in project selection decisions.

6. Statement of Work The basic guideline for the preparation of the SOW is that any activity, service or product required by the customer, and agreed to by the developer, must be included. The formal SOW must include all and only the work to be performed. This condition prevents misunderstandings and disagreements later, after the project begins.

7. 1. Referenced documents requirements specification existing system description customer's RFP developer's proposal vendor's and developer's technical literature 2. Software deliverables functionality (as documented in the requirements specification) list of major software components 3. Equipment and hardware deliverables functionality (as documented in the requirements specification) list of major hardware components 4. Training user courses operator training installation training A sample SOW outline for a software project

8. 5. Market research 6. Procurement 7. Supervision of subcontractors 8. Documentation development documentation user documentation maintenance documentation other technical documentation 9. Testing alpha testing beta testing acceptance tests (ATP) 10. Installation 11. Maintenance services 12. Other services and deliverable items 13. Method of delivery

9. Statement of Work The statement of work should be Clear Complete Concise It should include a description of any collateral services required performance reporting post-project operational support.

10. Software Development Lifecycle Water Fall Theme Software development, just like most other activities, has a beginning, middle and an end. The end of one development activity is sometimes perceived as being linked to the beginning of a new development activity.

11. SDLC There are many variations of the software development life cycle. presents a simple life cycle that was common during the first few decades of software development. In those early days of software development, the programmer would create programs by iterating from code to fix then back to code, and then to fix again, until something acceptable was (hopefully) produced.

12. SDLC (Water fall) Figure presents the basic phased model of a software development cycle. This model, called the Waterfall model, gets its name from the way in which each phase cascades into the next (due to overlapping), as demonstrated.

15. Conception Phase The concept phase involves a rough assessment of the project, why it may be beneficial, and preliminary cost estimates. Projects that require too large an investment in time, or are inappropriate or too expensive for an organization, should be disregarded or culled at this time. Software Requirement And analysis All possible requirements of the system to be developed are captured in this phase and documented in a requirement specification document.

16. Top Level Design Decompose into subsystems/modules. Architectural Design, Preliminary Design, Product Design. Input: SRD Outputs: Architectural Design Document (ADD) (Deliverable). System Test Document (STD) (Deliverable). Milestone: Architectural Design Review.

17. Detail Design Decompose further into subsystems (or units or components) Input: ADD. Outputs: Detailed Design Document (DDD). Detailed Test Document (specifications and test data). Milestone: Detailed Design Review.

18. Implementation / Coding With inputs from system design, the system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality which is referred to as Unit Testing.

19. Testing System Test You should now have a working system! The full system is tested, in the developers environment. Acceptance Test Assess the system against the requirements defined in SRD. Probably done under users control and supervision, and in their environment. Final payment hinges on this.

20. Maintenance Correction Correct defects in the software: defects relating to incorrect requirements, or incorrectly specifications; defects from any of the construction phases - `bugs'. Adaption Adapt to changes in the original software and hardware platform. E.g. simpler: MS- DOS to Windows. Complex: stand-alone to client-server. Enhancement Customer identifies additional requirements. Prevention After many sets of changes, the software `deteriorates', or otherwise becomes difficult to maintain. See Reengineering, Legacy Systems.

21. The Spiral model The Spiral model, described by Boehm (1988), is another development method that iterates between the requirements, design and implementation phases. However, the Spiral model continues iterating until the final system is complete. Within each, iteration, the Spiral model follows a phased approach similar to the Waterfall model

22. Spiral Model Spiral Model design The spiral model has four phases. A software project repeatedly passes through these phases in iterations called Spirals. Identification: This phase starts with gathering the business requirements in the baseline spiral. In the subsequent spirals as the product matures, identification of system requirements, subsystem requirements and unit requirements are all done in this phase.

23. Spiral Model Design: Design phase starts with the conceptual design in the baseline spiral and involves architectural design, logical design of modules, physical product design and final design in the subsequent spirals. Construct or Build: Construct phase refers to production of the actual software product at every spiral. In the baseline spiral when the product is just thought of and the design is being developed a POC (Proof of Concept) is developed in this phase to get customer feedback.

24. Spiral Model Evaluation and Risk Analysis: Risk Analysis includes identifying, estimating, and monitoring technical feasibility and management risks, such as schedule slippage and cost overrun. After testing the build, at the end of first iteration, the customer evaluates the software and provides feedback.

26. Spiral model

27. Spiral Model Different models maybe suitable for different software projects or for different software development organizations. However, a good model must include certain fundamental features. Some of these basic requirements are discussed in IEEE Standard (IEEE 1993) Standard for Software Life Cycle Processes. Most modern software development models, and certainly those following IEEE Standard 1074, include some form of the basic phased model

28. Prototyping The Software Prototyping refers to building software application prototypes which display the functionality of the product under development but may not actually hold the exact logic of the original software. Software prototyping is becoming very popular as a software development model, as it enables to understand customer requirements at an early stage of development. It helps get valuable feedback from the customer and helps software designers and developers understand about what exactly is expected from the product under development.

29. Prototyping What is Software Prototyping? Prototype is a working model of software with some limited functionality. The prototype does not always hold the exact logic used in the actual software application and is an extra effort to be considered under effort estimation. Prototyping is used to allow the users evaluate developer proposals and try them out before implementation. It also helps understand the requirements which are user specific and may not have been considered by the developer during product design.

30. Prototyping Following is the stepwise approach to design a software prototype Basic Requirement Identification Developing the initial Prototype The initial Prototype is developed in this stage, where the very basic requirements are showcased and user interfaces are provided. Review of the Prototype The prototype developed is then presented to the customer and the other important stakeholders in the project. Revise and enhance the Prototype The feedback and the review comments are discussed during this stage and some negotiations happen with the customer based on factors like, time and budget constraints and technical feasibility of actual implementation.

31. Software Prototyping Types Throwaway/Rapid Prototyping Throwaway prototyping is also called as rapid or close ended prototyping. This type of prototyping uses very little efforts with minimum requirement analysis to build a prototype. Once the actual requirements are understood, the prototype is discarded and the actual system is developed with a much clear understanding of user requirements. Evolutionary Prototyping Evolutionary prototyping also called as breadboard prototyping is based on building actual functional prototypes with minimal functionality in the beginning. The prototype developed forms the heart of the future prototypes on top of which the entire system is built. Using evolutionary prototyping only well understood requirements are included in the prototype and the requirements are added as and when they are understood

32. Software Prototype Incremental Prototyping: Incremental prototyping refers to building multiple functional prototypes of the various sub systems and then integrating all the available prototypes to form a complete system. Extreme Prototyping : Extreme prototyping is used in the web development domain. It consists of three sequential phases. First, a basic prototype with all the existing pages is presented in the html format. Then the data processing is simulated using a prototype services layer. Finally the services are implemented and integrated to the final prototype. This process is called Extreme Prototyping used to draw attention to the second phase of the process, where a fully functional UI is developed with very little regard to the actual services.

33. The Incremental Model The Incremental model is an example of an evolutionary life cycle model. It combines the linear nature of the Waterfall model and the iterative nature of the Prototyping model. Incremental model in software engineering is a one which combines the elements of waterfall model which are then applied in an iterative manner. It basically delivers a series of releases called increments which provide progressively more functionality for the client as each increment is delivered.

34. Incremental Model In incremental model of software engineering, waterfall model is repeatedly applied in each increment.waterfall model Advantages Initial product delivery is faster. Lower initial delivery cost. Core product is developed first i.e main functionality is added in the first increment. With each release a new feature is added to the product. Customer can respond to feature and review the product. Risk of changing requirement is reduced Work load is less.

35. Incremental Model Requires good analysis. Resulting cost may exceed the cost of the organization. As additional functionality is added to the product, problems may arise related to system architecture which were not evident in earlier prototypes.prototypes