Chapter 2: Software Engineering Lifecycle PDF

Chapterlifecycle 2 The software engineering Certificate in Software Product Engineering Page 1 of 31 Confidentiality Statement This document should not be carried outside the physical and virtual boundaries of TCS and its client work locations. Sharing this document with any person other than a TCS...

Chapterlifecycle 2 The software engineering Certificate in Software Product Engineering Page 1 of 31 Confidentiality Statement This document should not be carried outside the physical and virtual boundaries of TCS and its client work locations. Sharing this document with any person other than a TCS associate would tantamount to violation of confidentiality agreement signed by you while joining TCS. Notice The information given in this course material is merely for reference. Certain third party terminologies or matter that may be appearing in the course are used only for contextual identification and explanation, without an intention to infringe. Certificate in Software Product Engineering TCS Business Domain Academy Contents Chapter - 2 The software product engineering lifecycle....................................................4 2.1 Software product development process................................................................ 5 2.2 The starting point to any product development process – Identifying needs.........6 2.3 Product Life cycle.................................................................................................. 7 2.4 Engineering roles and organizational structure......................................................8 2.5 SDLC traditional Methodology..............................................................................9 2.6 Agile methodologies............................................................................................20 Summary........................................................................................................................29 Page 3 of 31 Certificate in Software Product Engineering Chapter - 2 TCS Business Domain Academy The software product engineering lifecycle Introduction Software product engineering lifecycle presents a comprehensive overview of software development process, various stages of product lifecycle with varied organization structure. Details of various SDLC methodologies which are classified as traditional methodologies and agile methodologies and also list out the advantages and disadvantages of each methodology used. Learning Objective After completing this chapter you will be able to understand: Software Product development process Product development process overview Product Lifecycle SDLC traditional methodologies Agile methodologies Page 4 of 31 Certificate in Software Product Engineering 2.1 TCS Business Domain Academy Software product development process Regardless of the development methodology, representatives from Product, Marketing, Business, Design, and Engineering should be involved to some extent from the very beginning of the process Having said that, it is essential that the responsibility lies with one person to own the product development process (i.e. be accountable for its success) from initiation to launch, and that person essentially will be Product Manager/Product Owner. He/she is a facilitator between all the different stakeholders of a product and they are able to get through product development on time and on budget, every time and with consensus between all the stakeholders involved in the process. The roles of the Responsible (R), Supporter (S), and Informed (I) are important to define for each of the product development stages. There should be only one person defined as responsible “R” for each step in order to avoid confusion and reporting conflict, which doesn’t necessarily mean that this person does all the work, but this person is ultimately responsible to get the work done (with help from the supporters). This model presented below in figure is designed in such a way that it works for any organizational structure, project size, and timeline. If it’s a large project then more time can be spent on each step. Similarly if the project has a tight timelines, that doesn’t mean that a stage needs to be skipped, it’s just that we need to spend less time (but effective time) on each stages. Below Figure 1 depicts the product development process Page 5 of 31 Certificate in Software Product Engineering TCS Business Domain Academy Figure 1 : Product Development Process 2.2 The starting point to any product development process – Identifying needs. At the beginning of any project (new or iterative), it is important to gather and blend needs from three sources: User needs Business needs Technical needs Page 6 of 31 Certificate in Software Product Engineering TCS Business Domain Academy User needs: This is the essential stage in gathering inputs for product decisions; everyone having this understanding allows organization to build products that matter to users, mainly the product manager (the person responsible for product) needs to have a good understand of the following market, the target segments, customer’s behaviors and attitudes. Below mentioned are four sources of user input: 1. Market research (segmentation, etc.), 2. user experience research (usability studies, ethnographic explorations), 3. site analytics (behavioral analysis), and 4. Customer support (call transcripts, interviews with CS reps, etc.). Business needs: we often here from executive team, “If you fix the user experience, you fix the business.” Fixing user experience comes at the cost of additional cost incurring features in the product, which is not always true, for any product there are value added features and non-value added features there are features for which customers are willing to pay for and which gives at most great user experience, so business should focus on such important functionalities to fix the business one should have clarity on why are we doing this so people will buy it, or people will want to use it and be willing to pay for it? Technology needs. Engineering needs to be at the involved from the initial phase as they know the in and out of product and limitations/technical constraints of the product, they know what is to be fixed; Having engineering and product working together is essential in good product development. 2.3 Product Life cycle A software development life cycle (SDLC) includes the software processes used to specify and transform software requirements into a deliverable software product. A software product life cycle (SPLC) includes a software development life cycle plus additional software processes that provide for deployment, maintenance, support, evolution, retirement, and all other inception-to-retirement processes for a software product, including the software configuration management and software quality assurance processes that are applied throughout a software product life cycle. A software product life cycle may include multiple software development life cycles for evolving and enhancing the software. Page 7 of 31 Certificate in Software Product Engineering TCS Business Domain Academy Individual software processes have no temporal ordering among them. The temporal relationships among software processes are provided by a software life cycle model: either an SDLC or SPLC. Life cycle models typically emphasize the key software processes within the model and their temporal and logical interdependencies and relationships. Linear SDLC models are sometimes referred to as predictive software development life cycle models, while iterative and agile SDLCs are referred to as adaptive software development life cycle models. It should be noted that various maintenance activities during an SPLC can be conducted using different SDLC models, as appropriate to the maintenance activities. As depicted in the Figure 2 below Product Management cuts across the SPLC and forms the basis of development of quality software product. Requirement management occupies larger chunk of product management work and is spread across almost all phases except for some final release phase. Figure 2: Software Product Life cycle (SPLC) 2.4 Engineering roles and organizational structure In most top-software product organizations product engineering teams are part of the R & D division. Teams inside R & D are organized typically based on the size of the team and its product portfolio. Teams are grouped under the particular product domain and develop a functional structure. As the organization grows it establishes a more complex matrix or product team structure Page 8 of 31 Certificate in Software Product Engineering TCS Business Domain Academy Functional Structure A function is a group of people working together who possess similar skills or use the same knowledge, tools, or techniques to perform their jobs. A typical functional structure in software product organization would be composed of Development, QA, Product Management, Project Management, Operations, Support, UX Design, Build Team etc. Matrix Structure In a matrix structure, managers group people in two ways simultaneously: by function and by product. The result is a complex network of reporting relationships that makes the matrix structure very flexible. Each person in a product team reports to two bosses: 1) a functional boss, who assigns individuals to a team and evaluates their performance, and 2) the boss of the product team, who evaluates their performance on the team. Product teams are empowered and team members are responsible for making important decisions, to keep the matrix structure flexible. Matrix structures have been successfully used for years at high-tech companies where new product development takes place frequently and the need to innovate quickly is vital to the organization’s survival. Details of product team structure, product delivery team are explained in additional reading 2.5 SDLC traditional Methodology This phase include the various software development methodologies i.e. system development life cycle (SDLC) Every software development methodology approach acts as a basis frameworks to develop and maintain software. Several software development approaches have been used since the origin of information technology. It can be classified based on traditional methodology and iterative & incremental development; these approaches are also referred as "Software Development Process Models". Each process model follows a particular life cycle in order to ensure success in process of software development. 1. Software development life cycle methodology (traditional methodology) 2. Agile methodology (Iterative/incremental methodology) Page 9 of 31 Certificate in Software Product Engineering TCS Business Domain Academy There are many models under these methodologies: 1. Software development life cycle as shown in below Figure 3 o Waterfall: a sequential development framework o Spiral: a combined approach of sequential-iterative framework o Iterative: a framework where small portions of software is developed by combined approach of sequential and iterative o Prototyping: an iterative framework by creating the prototypes o Rapid application development (RAD): an iterative framework Figure 3 Traditional SDLC methodologies Waterfall methodology Waterfall approach was the first Process Model to be introduced and followed widely in Software Engineering to ensure success of the project. In "The Waterfall" approach, the whole process of software development is divided into separate process phases. The phases in Waterfall model are: Requirement Specifications Phase, Software Design Phase, implementation, testing & Maintenance as shown in below Figure 4. All these phases are cascaded to each other so that second phase is started as and when defined set of goals are achieved for the first phase and it is signed off, so the name "Waterfall Model". All the methods and processes undertaken in the Waterfall Model are more visible. Page 10 of 31 Certificate in Software Product Engineering TCS Business Domain Academy Figure 4 : Waterfall methodology The stages of "The Waterfall Model" include Requirement Analysis & Definition: All possible requirements of the system to be developed are captured in this phase. Requirements are a set of functionalities and constraints that the end-user (who will be using the system) expects from the system. The requirements are gathered from the endusers by consultation, these requirements are analyzed for their validity and the possibility of incorporating the requirements in the system to be development is also studied. Finally, a Requirement Specification document is created which serves as a guideline for the next phase of the model. System & Software Design Before starting the actual coding, it is very important to understand what we are going to create and what it should look like ?The requirement specifications from the first phase are studied in this phase and the system design is prepared. System Design helps in specifying the hardware and system requirements and also helps in defining overall system architecture. The system design specifications serve as input for the next phase of the model. Implementation & Unit Testing Page 11 of 31 Certificate in Software Product Engineering TCS Business Domain Academy On receiving system design documents, the work is divided into modules/units and actual coding is started. 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; this is referred to as Unit Testing. Unit testing mainly verifies if the modules/units meet their specifications. Integration & System Testing As specified previously, the system is first divided in units which are developed and tested for their functionalities. These units are then integrated into a complete system during the Integration Phase and tested to check if all modules/units coordinate between each other and the system as a whole behaves as per the specifications. After successfully testing the software, it is delivered to the customer. Operation & maintenance This phase is virtually never ending phase (very long). Generally, problems with the system developed (which are not found during development life cycle) come up after its practical use starts, so the issues related to the system are solved after deployment of the system. Not all the problems come into picture directly but they arise time to time and needs to be solved, hence this process is referred as maintenance. Advantages and Disadvantages of the Waterfall Model Advantages The advantage of waterfall development is that it allows for departmentalization and managerial control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process like a car in a carwash, and theoretically, be delivered on time. Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order, without any overlapping or iterative steps. Disadvantages The disadvantage of waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change Page 12 of 31 Certificate in Software Product Engineering TCS Business Domain Academy something that was not well-thought out in the concept stage. Alternatives to the waterfall model include joint application development (JAD), rapid application development (RAD), synch and stabilize, build and fix, and the spiral model. Iterative Model Start Complete d Requiremen ts Design Review Implementa tion and Test Figure 5 : Iterative Methodology An iterative lifecycle model does not attempt to start with a full specification of requirements. Instead, development begins by specifying and implementing just part of the software, which can then be reviewed in order to identify further requirements. This process is then repeated, producing a new version of the software for each cycle of the model as shown in Figure 5. Consider an iterative lifecycle model which consists of repeating the following four phases in sequence Requirements phase In which the requirements for the software are gathered and analyzed. Iteration should eventually result in a requirements phase that produces a complete and final specification of requirements Design phase In which a software solution to meet the requirements is designed. This may be a new design, or an extension of an earlier design Page 13 of 31 Certificate in Software Product Engineering TCS Business Domain Academy Implementation and Test phase When the software is coded, integrated and tested Review Phase This is the phase in which the software is evaluated, the current requirements are reviewed, changes and additions to the requirements are proposed For each cycle of the model, a decision has to be made as to whether the software produced by the cycle will be discarded, or kept as a starting point for the next cycle (sometimes referred to as incremental prototyping). Eventually a point will be reached where the requirements are complete and the software can be delivered, or it becomes impossible to enhance the software as required, and a fresh start has to be made The iterative lifecycle model can be like producing software by successive approximation. Drawing an analogy with mathematical methods that use successive approximation to arrive at a final solution, the benefit of such methods depends on how rapidly they converge on a solution. The key to successful use of an iterative software development lifecycle is rigorous validation of requirements, and verification (including testing) of each version of the software against those requirements within each cycle of the model The first three phases of the example iterative model is in fact an abbreviated form of a sequential V or waterfall lifecycle model. Each cycle of the model produces software that requires testing at the unit level, for software integration, for system integration and for acceptance. As the software evolves through successive cycles, tests have to be repeated and extended to verify each version of the software. Advantages and disadvantages The advantage of this model is that there is a working model of the system at a very early stage of development which makes it easier to find functional or design flaws. Finding Page 14 of 31 Certificate in Software Product Engineering TCS Business Domain Academy issues at an early stage of development enables to take corrective measures in a limited budget. The disadvantage with this SDLC model is that it is applicable only to large and bulky software development projects. This is because it is hard to break a small software system into further small serviceable increments/modules. Spiral Model History The spiral model was defined by Barry Boehm in his 1988 article A Spiral Model of Software Development and Enhancement. This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration matters. As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project. The Spiral Model: The spiral model, also known as the spiral lifecycle model, is a systems development method (SDM) used in information technology (IT). 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. The steps in the spiral model can be generalized as follows: o The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system. o A preliminary design is created for the new system. o A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product. o A second prototype is evolved by a fourfold procedure: (1) evaluating the first prototype in terms of its strengths, weaknesses, and risks; (2) defining the Page 15 of 31 Certificate in Software Product Engineering TCS Business Domain Academy requirements of the second prototype; (3) planning and designing the second prototype; (4) constructing and testing the second prototype. o At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product. o The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above. o The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired. o The final system is constructed, based on the refined prototype. o The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime. Advantages and Disadvantages of the Spiral Model Advantages 1. Estimates (i.e. budget, schedule, etc.) become more realistic as work progresses, because important issues are discovered earlier. 2. It is more able to cope with the (nearly inevitable) changes that software development generally entails. 3. Software engineers (who can get restless with protracted design processes) can get their hands in and start working on a project earlier. Disadvantages 1. Highly customized limiting re-usability 2. Applied differently for each application 3. Risk of not meeting budget or schedule Page 16 of 31 Certificate in Software Product Engineering TCS Business Domain Academy RAD Model RAD (rapid application development) is a concept that products can be developed faster and of higher quality through below Figure 6 Some companies offer products that provide some or all of the tools for RAD software development. (The concept can be applied to hardware development as well.) These products include requirements gathering tools, prototyping tools, computer-aided software engineering tools, language development environments such as those for the Java platform, groupware for communication among development members, and testing tools. RAD usually embraces object oriented programming methodology, which inherently fosters software re-use. The most popular object-oriented programming languages, C++ and Java, are offered in visual programming packages often described as providing rapid application development Figure 6 : RAD Model Development Methodology The traditional software development cycle follows a rigid sequence of steps with a formal sign-off at the completion of each. A complete, detailed requirements analysis is done that attempts to capture the system requirements in a Requirements Specification. Users are Page 17 of 31 Certificate in Software Product Engineering TCS Business Domain Academy forced to "sign-off" on the specification before development proceeds to the next step. This is followed by a complete system design and then development and testing. RAD is a methodology for compressing the analysis, design, build, and test phases into a series of short, iterative development cycles shown in below Figure 7. This has a number of distinct advantages over the traditional sequential development model. Figure 7 : RAD Development Methodology RAD projects are typically staffed with small integrated teams comprised of developers, end users, and IT technical resources. A small team, combined with short, iterative development cycles optimizes speed, unity of vision and purpose, effective informal communication and simple project management RAD Model Phases RAD model has the following phases: 1. Business Modeling: The information flow among business functions is defined by answering questions like what information drives the business process, what information is generated, who generates it, where does the information go, who process it and so on 2. Data Modeling: The information collected from business modeling is refined into a set of data objects (entities) that are needed to support the business. The attributes (character of each entity) are identified and the relation between these data objects (entities) is defined. Page 18 of 31 Certificate in Software Product Engineering TCS Business Domain Academy 3. Process Modeling: The data object defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting or retrieving a data object 4. Application Generation: Automated tools are used to facilitate construction of the software; even they use the 4th GL techniques. 5. Testing and Turn over: Many of the programming components have already been tested since RAD emphasis reuse. This reduces overall testing time. But new components must be tested and all interfaces must be fully exercised. Advantages and Disadvantages of the RAD Model RAD reduces the development time and reusability of components help to speed up development. All functions are modularized so it is easy to work with. For large projects RAD require highly skilled engineers in the team. Both end customer and developer should be committed to complete the system in a much abbreviated time frame. If there is lack of commitment RAD will fail. RAD is based on Object Oriented approach and if it is difficult to modularize the project the RAD may not work well. Prototyping Model A prototype is a working model that is functionally equivalent to a component of the product. In many instances the client only has a general view of what is expected from the software product. In such a scenario where there is an absence of detailed information regarding the input to the system, the processing needs and the output requirements, the prototyping model may be employed. This model reflects an attempt to increase the flexibility of the development process by allowing the client to interact and experiment with a working representation of the product. The developmental process only continues once the client is satisfied with the functioning of the prototype. At that stage the developer determines the specifications of the client’s real needs. Page 19 of 31 Certificate in Software Product Engineering 2.6 TCS Business Domain Academy Agile methodologies Agile SDLC implements both iterative and incremental process models the key factors of agile methodology include process adaptability and customer satisfaction by rigorous testing and rapid delivery of working software product. These methods break the product into small incremental builds. These builds are provided in iterations. Each iteration typically lasts from about one to three weeks. Every iteration involves cross functional teams working simultaneously on various areas like planning, requirements analysis, design, coding, unit testing, and acceptance testing. At the end of the iteration a working product is displayed to the customer and important stakeholders. As shown in Figure 8 below Figure 8 : Agile software development methodology Manifesto for Agile Software Development Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Agile Project Management Qualities: Minimize risk
short iterations Real-time communication (prefer face-to-face)
very little written documentation Page 20 of 31 Certificate in Software Product Engineering TCS Business Domain Academy Indicated for unpredictable / rapidly changing requirements Scrum Scrum projects make progress in a series of “sprints, sprint is the basic unit of development. Each sprint is preceded by a planning meeting, where the tasks for the sprint are identified and an estimate for the sprint goal is made, and followed by a review meeting in which progress is reviewed and tasks for the next sprint are identified. Team creates finished product by the end of each sprint. Components of Scrum – Scrum Roles – The Process – Scrum Artifacts 2.6.1.1 Scrum Roles: Scrum Master: Represents management to the project Typically filled by a Project Manager or Team Leader Responsible for enacting scrum values and practices Main job is to remove impediments The Scrum Team: Typically 5-10 people Cross-functional (QA, Programmers, UI Designers, etc.) Members should be full-time Team is self-organizing Membership can change only between sprints Page 21 of 31 Certificate in Software Product Engineering TCS Business Domain Academy Product Owner Acts like one voice (in any case) Knows what needs to be build and in what sequence this should be done Typically a product manager 2.6.1.2 The Process Sprint Planning Meeting Sprint Daily Scrum Sprint Review Meeting Figure 9 : Scrum Process Sprint Planning Meeting A collaborative meeting in the beginning of each Sprint between the Product Owner, the Scrum Master and the Team Takes 8 hours and consists of 2 parts (“before lunch and after lunch”) 1st Part: Creating Product Backlog Determining the Sprint Goal. Participants: Product Owner, Scrum Master, Scrum Team 2nd Part: Participants: Scrum Master, Scrum Team Page 22 of 31 Certificate in Software Product Engineering TCS Business Domain Academy Creating Sprint Backlog Pre-Project/Kickoff Meeting A special form of Sprint Planning Meeting Meeting before the begin of the Project Sprint A month-long iteration, during which is incremented a product functionality NO outside influence can interference with the Scrum team during the Sprint Each Sprint begins with the Daily Scrum Meeting Daily Scrum Is a short (15 minutes long) meeting, which is held every day before the Team starts working Participants: Scrum Master (which is the chairman), Scrum Team Every Team member should answer on 3 questions – What did you do since the last Scrum? – What are you doing until the next Scrum? – What is stopping you getting on with the work? Is a meeting in which team members make commitments to each other and to the Scrum Master Is a good way for a Scrum Master to track the progress of the Team Is NOT a problem solving session Is NOT a way to collect information about WHO is behind the schedule Sprint Review Meeting Is held at the end of each Sprint Business functionality which was created during the Sprint is demonstrated to the Product Owner Informal, should not distract Team members of doing their work Page 23 of 31 Certificate in Software Product Engineering TCS Business Domain Academy 2.6.1.3 Scrum Artifacts Product Backlog: Requirements for a system, expressed as a prioritized list of Backlog Items Is managed and owned by a Product Owner Spreadsheet (typically) Usually is created during the Sprint Planning Meeting Can be changed and re-prioritized before each PM Sprint Backlog A subset of Product Backlog Items, which define the work for a Sprint Is created ONLY by Team members Each Item has its own status Should be updated every day No more than 300 tasks in the list If a task requires more than 16 hours, it should be broken down Team can add or subtract items from the list. Product Owner is not allowed to do it Burn down Charts Are used to represent “work done”. Are wonderful Information Radiators 3 Types: – Sprint Burn down Chart (progress of the Sprint) – Release Burn down Chart (progress of release) – Product Burn down chart (progress of the Product) Advantages and disadvantages of scrum Advantages: Completely developed and tested features in short iterations Simplicity of the process Clearly defined rules Increasing productivity Self-organizing Page 24 of 31 Certificate in Software Product Engineering Each team member carries a lot of responsibility Improved communication Combination with Extreme Programming TCS Business Domain Academy Disadvantages: “Undisciplined hacking” (no written documentation) Extreme programming XP is software development methodology intended and developed to increase the software quality and responsiveness to user requirement changes i.e adaptability, it backs software "releases" in short and frequent development cycles, thereby improve productivity and introduce checkpoints at which new/changing user requirements can be adopted. Extreme programming uses pair programming method, in which two programmers termed as “Driver” and “navigator/observer” are employed. Driver is the person responsible for writing the code whereas Observer is responsible for code review and he also consider the "strategic" direction of the work, coming up with ideas for improvements and likely future problems to address. This pair programming support extensive code review and unit testing. This reduces the bugs in the code and rework. Adaptive software development (ASD) Adaptive software development (ASD) is a software methodology that evolved from the concepts of RAD process and complexity theory.it is built on the concept of “Speculatecollaborate-learn” as shown in below Figure 10 Figure 10 : ASD Methodology Page 25 of 31 Certificate in Software Product Engineering TCS Business Domain Academy An ASD life cycle has six basic characteristics: 1. Mission focused 2. Feature based 3. Iterative 4. Time-boxed 5. Risk driven 6. Change tolerant Mission statements act as guides that encourage team to achieve the product development deadlines thus keeping them focused. A mission provides boundaries rather than a fixed destination. Without a good mission and a constant mission refinement practice, iterative life cycles become oscillating life cycles—swinging back and forth with no progress. Mission statements (and the discussions leading to those statements) provide direction and criteria for making critical project tradeoff decisions. The ASD life cycle focuses on results, not tasks, and the results are application features, which are the customer functionality that is to be developed during iteration. Features may evolve over several iterations as customers provide feedback on the working software developed and any changes to such are to be accommodated by the team. The practice of time-boxing, or setting fixed delivery times for iterations and projects, timeboxing is minimally about time—it was really about focusing and forcing hard tradeoff decisions. In an uncertain environment in which change rates are high, there needs to be a periodic forcing function to get work finished.. ASD process as shown in Figure 11 include Project initiation Iterative development process Final Review. Page 26 of 31 Certificate in Software Product Engineering TCS Business Domain Academy (Source highsmith 2000.) Figure 11: ASD Process Project initiation: 1. Specify the Project Mission, which defines the objectives to be achieved and broad requirements to be satisfied by the project. 2. Organize project team(s). 3. Create the Mission Artifacts; the necessary information for producing the artifacts is usually obtained through JAD sessions. 4. Obtain approval of the clients/sponsors and the permission to go ahead with the project. 5. Share mission values among the project community, through discussing and agreeing on quality objectives and evaluation criteria. Adaptive Cycle planning 1. Determine time boxes for the project and each development cycles; time boxes are typically between two to eight weeks in duration. 2. Write objective statements for the each development cycles. Page 27 of 31 Certificate in Software Product Engineering TCS Business Domain Academy 3. Define product components through JAD sessions; components are of three types: feature components (domain-specific and enact the business logic of the system); technology components and support components, which are domain independent and provide the technical infrastructure. 4. Assign components to cycles according to the risks involved in their development, by considering their interdependencies. 5. Develop a Project Task List, consisting of the tasks that should be performed during the remaining phases of the project. Concurrent component engineering 1. Develop the components assigned to the cycle. Working components are typically developed concurrently by development teams working in parallel and are delivered as builds on a daily or weekly basis. The produced builds are immediately fed into an integration process. Testing and refactoring are ongoing processes during this activity. 2. Manage the project through continuous monitoring and control. Maintaining the team collaboration and keeping the cycle on the right track are the main concerns. 3. Prepare for final Q/A by developing system-level test plans and test cases. 4. Prepare for quality review by planning the review meetings to take place in the Quality Review phase. Review: 1. Conduct cycle review by holding facilitated customer focus group sessions. The result of the cycle is presented to the customers. The feedback given by customers is taken as change requests which are carefully documented to be considered in later iterations. 2. Perform tests, with the main purpose of system-level validation and fix problems if any 3. 2. Decision is made on whether another iteration cycle should be initiated to accommodate the customer feedback, or the system should be prepared for release. 4. 3. Conduct cycle post-mortem, which typically reviews the performance of the teams and the effectiveness of the methods used so as to avoid occurrence of any problems in next cycles. Page 28 of 31 Certificate in Software Product Engineering TCS Business Domain Academy 5. 5. Close the project by summarizing lessons learned from the execution of the project. Summary Regardless of the development methodology, representatives from Product, Marketing, Business, Design, and Engineering should be involved to some extent from the very beginning of the process Needs are to be identified and gathered from three sources o User needs o Business needs o Technical needs A software development life cycle (SDLC) includes the software processes used to specify and transform software requirements into a deliverable software product A software product life cycle (SPLC) includes a software development life cycle plus additional software processes that provide for deployment, maintenance, support, evolution, retirement. In functional structure, a function is a group of people working together who possess similar skills or use the same knowledge, tools, or techniques to perform their jobs. In a matrix structure, managers group people in two ways simultaneously: by function and by product. Every software development methodology approach acts as a basis frameworks to develop and maintain software referred as "Software Development Process Models". o Software development life cycle methodology (traditional methodology) o Agile methodology (Iterative/incremental methodology) Software development life cycle: o Waterfall: a sequential development framework o Spiral: a combined approach of sequential-iterative framework Page 29 of 31 Certificate in Software Product Engineering o TCS Business Domain Academy Iterative: a framework where small portions of software is developed by combined approach of sequential and iterative o Prototyping: an iterative framework by creating the prototypes o Rapid application development (RAD): an iterative framework Agile methodologies include Scrum, Extreme programming, Adaptive software development. Page 30 of 31