IM02-Software-Process.pdf

ITPC4 – Software Engineering Module 2 Chapter 2 Software Process This lesson introduces you to software development as a process. It explains the process as a framework that consists of phases. You will encounter different software development...

ITPC4 – Software Engineering Module 2 Chapter 2 Software Process This lesson introduces you to software development as a process. It explains the process as a framework that consists of phases. You will encounter different software development approaches and practices highlighting their advantages, disadvantages, and their application to different software development projects. At the end of this lesson, you should be able to: 1. show understanding of the software development process; 2. differentiate the three approaches to software development; and 3. apply the appropriate approach to software development projects. 1 The Software Process Software Process provides the strategy used by the development team to build quality software. It is the collection of framework activities, task sets or actions, and umbrella activities. Activity or framework activities aims to achieve a broad objective. They are performed by the people involved in the development. They are also known as the phases of the software development process. An example is the modeling phase of a generic software process. Tasks focus on small but well-defined objective that produces a tangible output. A task set or action produces a major work product based on the output of one or more tasks. An example of a task is the specification task in the requirements engineering task set in the modeling phase of a generic software process. Umbrella Activities support the framework activities such that they are performed as the project progresses. These include software project management, change management, requirements management, risk management, formal technical reviews etc. A software process is chosen based on the following factors: 1. nature of project; 2. methods and tools to be used; 3. requirements of the stakeholder; and 4. common sense and judgment. 1 ITPC4 – Software Engineering Module 2 2 Generic Process Framework Process Framework establishes a complete software engineering process by identifying framework activities. It also includes umbrella activities that are applicable across the entire process. A generic process framework encompasses five activities: Communication is where customers and stakeholders communicate and collaborate to understand the objectives and gather requirements that help define the functions and features of the software. Planning creates the software project plan that describes the tasks to be done, the risks, resources, work products and work schedule that will guide the team. Modeling is the activity dedicated in creating the blueprint and models to better understand the system. It is usually an iterative process that refines the model into greater detail to better understand the requirements. Construction is the combination of coding and testing which is based on the model created. Deployment is performed to deliver the complete software to the stakeholders who will then evaluate the product and provide feedback. 3 Generic Process Models Process Models suggest how to build software using a specific model. These models follow a process flow which is how the activities are organized in relation to time and sequence. Generic Process Models follow four process flows and were the basis for other models. LINEAR – executes the framework activities in sequence. ITERATIVE – repeats one or more activities before proceeding to the next. 2 ITPC4 – Software Engineering Module 2 EVOLUTIONARY – otherwise known as incremental, executes the activities in circular manner where each circuit leads to a more complete version of the software. PARALLEL – executes one or more activities in parallel with other activities. 4 Systems Development Lifecycles (SDLC) The traditional approach to software development is the Waterfall Lifecycle. It is a rigid sequence of phases where each phase is focused on a specific aspect of the software product to be produced. A pure waterfall approach might consist of the following phases: Project Initiation: define terms of reference; high-level investigation and estimates; preliminary exploration of problems and possible solutions; benefits versus costs of candidate solutions; recommendation of one option. Analysis: investigate, document and assess current system; gather and document new requirements; requirements documentation produced and signed off. Design: design new/enhanced business system, design user interfaces, produce business system specifications. 3 ITPC4 – Software Engineering Module 2 Build and Test: perform detailed technical design; deconstruct business system specifications further into units or components; specify the components; code and test components; components are brought together to form higher level systems and tested. Implementation: train staff, user acceptance testing and handover. Review: post implementation review of project and system. The V-Model is not really an SDLC itself, but a model of the testing workflow using a waterfall style. On the left of the model is static testing which is the inspection of documentation about the software, such as requirements. Test plans are laid out for various aspects of the software. On the right side, we see dynamic testing or the execution of the test plans, which include reporting on findings and taking appropriate action. Although there are several variants of the V-Model, a common type of V-Model uses five (5) test levels that correspond to five (5) development levels: 1. Component (Unit) Testing 2. Component Integration Testing 3. System Testing 4. System Integration Testing 5. Acceptance Testing 4.1 Linear or Waterfall Approach Waterfall Approach follow a linear-sequential flow that seems like the natural way of software development project. The project proceeds along clearly defined phases and a preceding phase must be completed or ‘signed off’ before the next starts. Except for well understood cases, it may be difficult to completely define requirements at the beginning. Hence, the prototyping practice is often used to aid requirements elicitation. Furthermore, it is impossible in a waterfall approach to accommodate changes to requirements at a late stage. 4 ITPC4 – Software Engineering Module 2 The waterfall approach is suitable when there is: 1. low degree of business change; 2. requirements are clearly understood; and 3. tools, architecture and infrastructures are well-understood. Advantages Safe and ‘signed off’ Thorough Quality built in Easy to manage Design based on all requirements and interfaces Good documentation Disadvantages Can’t go back Lack of user involvement No early vision of system Difficult to add missing requirements Business change has high impact Fosters ‘silo’ mentality 4.2 Incremental or Phased Approach The Incremental Approach is a method of software development where the system is designed, built, tested and implemented incrementally (a little more is added each time) until the product is completed. The product is considered complete when it satisfies all of its requirements. The product is broken down into a number of components, each of which are designed and built separately (termed as builds). Each of the components is delivered to the client when it is complete. Developing a system incrementally allows the developer to take advantage of what was learned during the development of earlier, incremental, deliverable of the system. 5 ITPC4 – Software Engineering Module 2 Advantages Early vision of system Earlier deliverables Reduces complexity and risk can be tackled earlier Easier to test and debug smaller increments Disadvantages Difficult to manage Users can still change their mind! May get partial solutions Additional costs of parallel implementation and regression testing 4.3 Iterative or Spiral Approach Iteration means a repeating cycle of steps, which commonly includes visiting several aspects of the software product. Development in the spiral approach is divided into a number of time boxed iterations that some people have likened to mini-waterfalls. The idea with this approach is to start with an implementation of a subset of the software requirements and incrementally enhance the product until the full system is implemented. At each iteration, design modifications may be made and new functional capabilities may be added. Developing a system in this approach allows the development team, which includes users, to take advantage of what was learned during the development of earlier deliverable versions of the system. Advantages Requirements evolve Flexible, incorporates change Plenty of user involvement Early vision of system User buy-in is higher Cost can be controlled 6 ITPC4 – Software Engineering Module 2 Disadvantages Difficult to manage multiple iterations and multiple iteration teams Shortcuts can be taken Hard to scope Scope creep, ‘gold-plating’ Complexity of integration testing can lead to higher costs The Dynamic System Development Method (DSDM) and the Unified Process (UP) are frameworks which support the iterative development of software. 4.3.1 Dynamic System Development Method Dynamic Systems Development Method (DSDM) was first released in 1994 by a consortium of organizations including Norwich Union, British Airways, American Express, and Oracle, to provide discipline to Rapid Application Development (RAD) Methods. DSDM fixes cost, quality and time at the outset and uses the MoSCoW prioritization of scope into musts, shoulds, coulds and won't haves to adjust the project deliverable to meet the stated time constraint. Today, the DSDM consortium, a non-organization, is the guardian of DSDM Atern, the latest (2007) version, which incorporates Agile practices. DSDM is in fact one form of Agile in the modern context. 7 ITPC4 – Software Engineering Module 2 4.3.2 Unified Process The Unified Software Development Process (USDP), from the authors of the UML, is also an iterative approach; in fact, USDP is the ancestor of Agile. It is commonly referred to as the Unified Process or UP. Projects are broken into small subprojects (the iterations) that deliver system functionality in chunks or increments leading to a fully functional system. Each iteration contains all of the elements of a normal software development project: planning, analysis and design, construction, integration and test. Each iteration generates a baselined increment that comprises a partially complete version of the final system and associated project documentation. The baselines build on each other over successive iterations until the product is considered releasable and able to contribute business value. 4.4 Selecting the Appropriate Approach In practice, it is more helpful to think of these three options as choices along a spectrum of approaches, from a formal structured approach at one end to a flexible, informal approach at the other end. Hence, for each project we should ask “should the development be run more towards the waterfall end of the spectrum or more towards the iterative end?” 8 ITPC4 – Software Engineering Module 2 5 Software Development Practices Whichever lifecycle is adopted, it may also be necessary to select certain development practices. A decision is needed at some stage as to whether the system will be acquired using a bespoke development or buying a software package. If bespoke approach is chosen, will an Agile practice be indicated? Will prototyping be useful as a way to confirm user requirements? Can existing components be re-used and re- configured? 5.1 Acquisition Options – Build or Buy Software can be acquired by commissioning a Bespoke Development (build), where software is written to the customer’s exact specification, or a Commercial Off-the-Shelf (COTS) package may be purchased (buy) when the requirements is for standard software already available from vendors. Bespoke (build) should be considered for software that supports unique enterprise processes, or processes crucial to the enterprise value creation process. Package (buy) should be considered to solve routine business problems, e.g., Payroll. The use of Enterprise Resource Planning (ERP) packages is another option. As previously discussed in the previous module, an ERP is designed to cover most of the routine functions of an entire business. The advantages of ERP are that you automatically get interoperability between modules and common data designs. Disadvantages include a huge upfront cost and considerable risk as the business tries to adapt to the constraints imposed by the ERP. The use of Cloud Services is yet another option. The idea of cloud services is the rental of software and paying only what is used, rather like water or electricity. The 9 ITPC4 – Software Engineering Module 2 advantages include avoiding the cost of ownership of IT, like infrastructure, easy to scale and 24/7 round the world availability. Disadvantages include security concerns and, at least at the moment, broadband coverage is not guaranteed everywhere. 5.2 Agile Development Bespoke development could be conducted as an Agile project. Agile is one form of iterative evolutionary approach discussed earlier, and has become popular. The focus is on working software produced quickly and in direct collaboration with the software users. The Agile Manifesto for Software Development states: “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more.” Agile as a practice is summed up as: “A group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The Agile approach is iterative, adaptable, rapid, cooperative, and quality-driven.” Examples of iterative, incremental, evolutionary approaches are the Dynamic Systems Development Method (DSDM) and the Unified Process (UP), including Extreme Programming (XP). 5.3 Prototyping All iterative approaches depend on using prototyping to some extent. A prototype is a mock- up of the required product so that the customer can appreciate and comment on what is being built. Prototypes can be: Paper-based drawings Screen dumps Demo software Working software Prototypes in most environments are thrown away, but for methods like Agile and UP, the production software is really just a prototype for the next version – the idea of perpetual evolution! The advantages of prototyping are that customers find it easier to comment on something visual, and prototyping supports incremental development, which provides the customer with early vision of the system and its functionality. The disadvantages are that the requirements and design work can become confused, as customers want to design the solution while the prototype is being used to gather 10 ITPC4 – Software Engineering Module 2 requirements. Also, because the prototype may look like a ‘real’ system, users may believe that the production process is more advanced than it really is. 5.4 Component-Based Development A software component is a system element offering a predefined service, and able to communicate with other components; a reusable program building block that can be combined with other components to form an application. Component-based development is at the heart of Object-Oriented (OO) approach. Component-based development states that software should be developed by gluing prefabricated components together much like in the field of electronics or mechanics. It claims that software components can be ultimately made interchangeable and reliable. 11