UNIT I SOFTWARE PROCESS Introduction S/W Engineering Paradigm life cycle models (water fall, incremental, spiral, WINWIN spiral, evolutionary, prototyping, objects oriented) -system engineering computer based system verification validation lifecycle process development process system engineering hierarchy. Key points: At the end of this chapter the student will be able to: Identify the scope and necessity of software engineering. Identify the causes of and solutions for software crisis. Differentiate a piece of program from a software product. Introduction to Software Engineering Specific Instructional Objectives At the end of this unit the student will be able to: Identify the scope and necessity of software engineering. Identify the causes of and solutions for software crisis. Differentiate a piece of program from a software product. Software Engineering Software engineering is the establishment and sound engineering principles applied to obtain reliable and efficient software in an economical manner. Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. Software engineering encompasses a process, management techniques, technical methods, and the use of tools.
Software engineering is that form of engineering that applies the principles of computer science and mathematics to achieving cost-effective solutions to software problems. Software process overview The roadmap to building high quality software products is software process. Software processes are adapted to meet the needs of software engineers and managers as they undertake the development of a software product. A software process provides a framework for managing activities that can very easily get out of control. Different projects require different software processes. The software engineer's work products (programs, documentation, data) are produced as consequences of the activities defined by the software process. The best indicators of how well a software process has worked are the quality, timeliness, and long-term viability of the resulting software product. Generic Software Engineering Phases Definition phase - focuses on what (information engineering, software project planning, and requirements analysis). Development phase - focuses on how (software design, code generation, software testing). Support phase - focuses on change (corrective maintenance, adaptive maintenance, perfective maintenance, preventative maintenance). Software Engineering Umbrella Activities Software project tracking and control Formal technical reviews Software quality assurance Software configuration management Document preparation and production Reusability management
Measurement Risk management Software Process Models Linear Sequential Model (old fashioned but reasonable approach when requirements are well understood) Prototyping Model (good first step when customer has a legitimate need, but is clueless about the details, developer needs to resist pressure to extend a rough prototype into a production product) Rapid Application and Development (RAD) Model (makes heavy use of reusable software components with an extremely short development cycle) Incremental Model (delivers software in small but usable pieces, each piece builds on pieces already delivered) Spiral Model (couples iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model) Win-Win Spiral Model (eliciting software requirements defined through negotiation between customer and developer, where each party attempts to balance technical and business constraints) Concurrent Development Model (similar to spiral model often used in development of client/server applications) Component-Based Development (spiral model variation in which applications are built from prepackaged software components called classes) Formal Methods Model (rigorous mathematical notation used to specify, design, and verify computer-based systems) Fourth Generation (4GT) Techniques (software tool is used to generate the source code for a software system from a high level specification representation) The General Model life cycle model Software life cycle models describe phases of the software cycle and the order in which those phases are executed. There are tons of models, and many companies adopt their own, but all have very similar patterns. The general, basic model is shown below:
General Life cycle model Each phase produces deliverables required by the next phase in the life cycle. Requirements are translated into design. Code is produced during implementation that is driven by the design. Testing verifies the deliverable of the implementation phase against requirements. Requirements Business requirements are gathered in this phase. This phase is the main focus of the project managers and stake holders. Meetings with managers, stake holders and users are held in order to determine the requirements. Who is going to use the system? How will they use the system? What data should be input into the system? What data should be output by the system? These are general questions that get answered during a requirements gathering phase. This produces a nice big list of functionality that the system should provide, which describes functions the system should perform, business logic that processes data, what data is stored and used by the system, and how the user interface should work. The overall result is the system as a whole and how it performs, not how it is actually going to do it.
Design The software system design is produced from the results of the requirements phase. Architects have the ball in their court during this phase and this is the phase in which their focus lies. This is where the details on how the system will work is produced. Architecture, including hardware and software, communication, software design (UML is produced here) are all part of the deliverables of a design phase. Implementation Code is produced from the deliverables of the design phase during implementation, and this is the longest phase of the software development life cycle. For a developer, this is the main focus of the life cycle because this is where the code is produced. Implementation my overlap with both the design and testing phases. Many tools exists (CASE tools) to actually automate the production of code using information gathered and produced during the design phase. Testing During testing, the implementation is tested against the requirements to make sure that the product is actually solving the needs addressed and gathered during the requirements phase. Unit tests and system/acceptance tests are done during this phase. Unit tests act on a specific component of the system, while system tests act on the system as a whole. So in a nutshell, that is a very basic overview of the general software development life cycle model. Now let s delve into some of the traditional and widely used variations. Waterfall Model This is the most common and classic of life cycle models, also referred to as a linearsequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed in its entirety before the next phase can begin. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project. Unlike what I mentioned in the general model, phases do not overlap in a waterfall model.
Waterfall Life Cycle model Advantages Simple and easy to use. Easy to manage due to the rigidity of the model each phase has specific deliverables and a review process. Phases are processed and completed one at a time. Works well for smaller projects where requirements are very well understood. Disadvantages Adjusting scope during the life cycle can kill a project No working software is produced until late during the life cycle. High amounts of risk and uncertainty. Poor model for complex and object-oriented projects. Poor model for long and ongoing projects. Poor model where requirements are at a moderate to high risk of changing.
V-Shaped Model Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes. Each phase must be completed before the next phase begins. Testing is emphasized in this model more so than the waterfall model though. The testing procedures are developed early in the life cycle before any coding is done, during each of the phases preceding implementation. Requirements begin the life cycle model just like the waterfall model. Before development is started, a system test plan is created. The test plan focuses on meeting the functionality specified in the requirements gathering. The high-level design phase focuses on system architecture and design. An integration test plan is created in this phase as well in order to test the pieces of the software systems ability to work together. The low-level design phase is where the actual software components are designed, and unit tests are created in this phase as well. The implementation phase is, again, where all coding takes place. Once coding is complete, the path of execution continues up the right side of the V where the test plans developed earlier are now put to use. V-Shaped Life Cycle Model
Advantages Simple and easy to use. Each phase has specific deliverables. Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle. Works well for small projects where requirements are easily understood. Disadvantages Very rigid, like the waterfall model. Little flexibility and adjusting scope is difficult and expensive. Software is developed during the implementation phase, so no early prototypes of the software are produced. Model doesn t provide a clear path for problems found during testing phases. PROTOTYPE MODEL When the developer is unsure of the efficiency of an algorithm, the adaptability of an operating system or the form that human machine interaction should take in this case prototype paradigm may offer the best approach. The prototyping paradigm beginning with requirements gathering. Developer and customer meet and define the overall objectives for the software and identify requirement. A Quick design then occurs. This quick design focuses on a representation of those aspects of the software that will be visible to the customer user. The prototype is evaluated by the customer and used to refine requirements for the software to be developed. Iteration occurs as the prototype is tuned to satisfy the need for the customer, while at the same time enabling the developer to better understand what needs to be done.
INCREMENTAL MODEL: This model combines the elements of the waterfall model with the iterative philosophy of prototyping. However, unlike prototyping the IM focuses on the delivery of an operational product at the end of each increment. More specifically, the model is designed, implemented and tested as a series of incremental builds until the product is finished. A build consists of pieces of code from various modules that interact together to provide a specific function. At each stage of the IM a new build is coded and then integrated into the structure, which is tested as a whole. Note that the product is only defined as finished when it satisfies all of its requirements. This model is based upon the recognition that software is built from smaller components. When an incremental model is used, the first increment is often a core product. i.e., basic requirements are addressed, but many supplementary features remain undelivered.
An example of this incremental approach is observed in the development of word processing applications where the following services are provided on subsequent builds: 1. Basic file management, editing and document production functions 2. Advanced editing and document production functions 3. Spell and grammar checking 4. Advance page layout Advantages Generates working software quickly and early during the software life cycle. More flexible less costly to change scope and requirements. Easier to test and debug during a smaller iteration. Easier to manage risk because risky pieces are identified and handled during its iteration. Each iteration is an easily managed milestone. Disadvantages Each phase of an iteration is rigid and do not overlap each other. Problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle. Spiral Model It describes the water fall and prototyping models.
The spiral model proposed by Boehm, is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model. Using the spiral model, software is developed in a series of incremental releases. A spiral model is divided into a number of framework activities also called task Regions. o Typically there are between three and six task regions. o In the model shown the task regions are as follows: Customer communication: Tasks required establishing effective communication between developer and customer. Planning: Tasks required to define resources, timelines and other project related information. Risk analysis: Tasks required to access both representations of management risks. Engineering: Tasks required to build one or more representation of the application. Constructions and release: Tasks required to construct, test, install and provide user support. Customer evaluation: Tasks required to obtain customer feedback based on evaluation of the software representation created during the engineering stage and implemented during the installation stage. Each of the regions is populated by a set of work tasks, called the task set, that are adapted to the characteristics of the project to be undertaken.
Advantages High amount of risk analysis Good for large and mission-critical projects. Software is produced early in the software life cycle. Disadvantages Can be a costly model to use. Risk analysis requires highly specific expertise. Project s success is highly dependent on the risk analysis phase. Doesn t work well for smaller projects. WINWIN SPIRAL: The Win Win Spiral Model uses Theory W (win-win) to develop software and system requirements, and architectural solutions, as win conditions negotiated among a project's stakeholders (user, customer, developer, maintainer, interface, etc.). The objective of this activity is to elicit project requirements from customer. The customer and developer enter into a process of negotiation, where the customer may be asked to balance functionality, performance and other product and time to market. ie., the customer wins by getting the system or product that satisfies the majority of the customer s and the developer wins by working to realistic and budgets and deadlines. Boehm s WINWIN spiral model defines a set of negations acticities at the beginning of each pass around the spiral.
(Additions to the spiral model shown in bold.) Single customer communication activity the following activities are defined. 1. Identification of the system or subsystem key stakeholders: 2. Determination of the stakeholders: win conditions. 3. Negotiations of the stakeholders win conditions to reconcile them into a set of win-win conditions for all concerned (including software project team). The emphasis placed on early negotiation, the WINWIN spiral model introduces three process milestones, called anchor points. The anchor points represent 3 different views of progress as the project traverses the spiral. 1. Life cycle objectives (LOC): Define set of objectives for each major software engineering activity. 2. Life cycle architecture (LOA): It establishes objectives that must be must be as the system and software architecture is defined. 3. Initial operational capability (IOC): It represents a set of objectives associated with the preparation of the software installation.
Object Oriented The object oriented process moves through an evolutionary spiral that starts with customer communication. It is here that the problem domain is defines and basic problem classes are defined. Planning and risk analysis establish a foundation for the Object Oriented project plan. The technical work associated with object oriented software engineering follows the iterative path shown in the shaded box. Object oriented software engineering emphasizes reuse. Therefore, classes are looked up in a library before they are built. When classes cannot found in the library, the software engineer applies o Object Oriented analysis (OOA), o Object Oriented design (OOD) o Object Oriented programming (OOP), and o Object Oriented testing (OOT) To create the classes and the objects derive ed from the classes. The new class is then put into the library so that it may be reused in the future. System engineering: Software engineering occurs as a consequence of a process called system engineering. Instead of concentrating solely on software, system engineering focuses on a variety of elements, analyzing, designing, and organizing those elements into a system that can be a product, a service, or a technology for the transformation of information. The system engineering process is called business process engineering when the context of the engineering work focuses on a business enterprise. When a product is to be built, the process is called product engineering.
Computer based systems. A set of arrangement of elements that are organized to accomplish some predefined goal by processing information. To accomplish a goal, a computer based system makes use of a variety of system elements: Software: Computer programs, data structures, and related documentation that serve to affect the goal logical methods, procedure, or control that is required. Hardware: Electronic devices that provide computing capability the interconnectivity devices that enable flow of data. People: Users and operators of hardware and software. Database: A large, organized collection of information that is accessed via software. Documentation. Descriptive information (e.g. hardcopy manual) that portrays the use and operation of the system. Procedures: The steps that define the specific use of each system element or the procedural context in which the system resides. The elements combine in a variety of ways to transform information. Example A marketing department transforms raw sales data into a profile of the typical purchaser of a product. A robot transforms a command file into a set of control signals. Verification and validation Software testing is one element of a broader topic that is often referred to as Verification and validation (V&V).
Verification refers to the set of activities that ensure that software correctly implements a specific function. Validation refers to a different set of activities ensure that the software that has been built is traceable to customer requirements. Verification: Are we building the product right? Validation: Are we building the right product? The definition of V&V encompasses many of the activities that we have referred to as software quality assurance (SQA). Verification and validation encompasses a wide array of SQA activities that include formal technical reviews, performance monitoring, simulation, review, etc.., Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the system customer. Involves checking and review processes and system testing. System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system. Software Verification and Validation plan. It Describe the overall plan for the verification and validation of the software. Identifies and describes the methods (e.g. Inspection, analysis, demonstration, or tests) Software Verification and Validation Report. It describes the results of the execution of the Software System Engineering Hierarchy System engineering encompasses a collection of top-down and bottom-up methods to navigate the hierarchy. The System engineering process usually begins with a world view.i.e., the entire business or product domain is examined to ensure that the proper business or technology context can be established. The worlds view is refined to focus more fully on specific domain of interest.
Stated in a slightly more manner, the world view (WV) is encompassed of a set of domain (Di), which can be each a system in its own right. WV= {D1, D2, D3 Dn} Each domain is encompassed of specific elements (Ei) each of which serves some role in accomplishing the objectives and goals of the domain. Di= {E1, E2, E3,.Em} Finally, each element is implemented by specifying the technical components (Ck) that achieve the necessary function for an element: Ei= {C1, C2, C3 Ck} A component could be a computer program, a reusable program component, a module, a class or even a programming language statement. Short answers: 1) Define Software Engineering. Software Engineering: The Application of systematic, disciplined, quantifier approach To the development, operations, and maintenance of software 2) What is a Process Framework? Process Framework : Establishes foundation for a complete software process By identifying a small number of framework activities that are applicable for all software projects regardless of their size and complexity 3) What are the Generic Framework Activities? Generic Framework Activities: Communication Planning Modeling Construction Deployment 4) Define Stakeholder. Stakeholder: Anyone who has stake in successful outcome of Project Business Managers, end-users, software engineer, support people
5) How the Process Model differ from one another? Based on flow of activities Interdependencies between activities Manner of Quality Assurance Manner of Project Tracking Team Organization and Roles Work Products identify an requirement identifier 6) Write out the reasons for the Failure of Water Fall Model? Reasons For The Failure Of Water Fall Model : Real Project rarely follow Sequential Flow. Iterations are made in indirect manner Difficult for customer to state all requirements explicitly Customer needs more patients as working product reach only at Deployment phase 7) What are the Drawbacks of RAD Model? Drawbacks of RAD Model: Require sufficient number of Human Resources to create enough number of teams Developers and Customers are not committed, system result in failure Not Properly Modularized building component may Problematic Not applicable when there is more possibility for Technical Risk 8) Why Formal Methods are not widely used? Quite Time Consuming and Expensive Extensive expertise is needed for developers to apply formal methods Difficult to use as they are technically sophisticated maintenance may become risk 9) What is Cross Cutting Concerns? Cross Cutting Concerns: When concerns cut across multiple functions, features and information 10) What are the different Phases of Unified Process? Different Phases of Unified Process: Inception Phase Elaboration Phase Construction Phase
Transition Phase Production Phase 11) Define the terms: a) Agility b) Agile Team a) Agility :- Dynamic, Content Specific, Aggressively Change Embracing and Growth Oriented b) Agile Team :- Fast Team Able to Respond to Changes 12) Define the terms: a) Agile Methods b) Agile Process a)agile Methods :- Methods to overcome perceive and actual weakness in conventional software engineering To accommodate changes in environment, requirements and use cases b)agile Process :- Focus on Team Structures, Team Communications, Rapid Delivery of software and it de-emphasis importance of intermediate product 13) What is the Use of Process Technology Tools? Use of Process Technology Tools: Help Software Organizations Analyze their current process Organize work task Control And Monitor Progress Manage Technical Quality 14) Define the term Scripts. Scripts: Specific Process Activities and other detailed work functions that are part of team process 15) What is the Objective of the Project Planning Process? Objective of the Project Planning Process: To provide framework that enables manager to make reasonable estimates of resources, cost and schedule
16) What are the Decomposition Techniques? Decomposition Techniques: Software Sizing Problem Based Estimation Process Based Estimation Estimation With Use Cases Reconciling Estimates 17) How do we compute the Expected Value for Software Size? Expected value for estimation variable (size), S, can be compute as Weighted Average of Optimistic(Sopt),most likely(sm),and Pessimistic(Spess) estimates S = (Sopt+4Sm+Spess)/6 18) What is an Object Point? Object Point : Count is determined by multiplying original number of object instances by weighting factor and summing to obtain total object point count 19) What is the difference between the Known Risks and Predictable Risks? Known Risks :- That can be uncovered after careful evaluation of the project plan, the business, and technical environment in which the product is being developed Example : Unrealistic delivery rate Predictable Risks :- Extrapolated from past project experience Example: Staff turnover 20) List out the basic principles of software project scheduling? Basic Principles Of Software Project Scheduling:- Compartmentalization Interdependency Time Allocation Effort Validation Defined Responsibilities Defined Outcomes Defined Milestones