Discussion on Papers

1. Discussion on Papers Lecture 5

2. Software Process:a roadmap Alfonso Fuggetta Politecnico di Milano and CEFRIEL http://www.cefriel.it/~alfonso

3. Goals of the paper Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

4. Software Lifecycle • A software lifecycle defines the different stages in the lifetime of a software product. • Typically, they are: • Requirements analysis and specification, • Design, development, verification and validation, • Deployment, operation, maintenance, and retirement. • A software lifecycle defines the principles and guidelines according to which these different stages have to be carried out. • Waterfall model suggests that a specific phase should be started only when the deliverables of the previous one have been completed • Spiral model considers software development as the systematic iteration of a number of activities driven by risk analysis. Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

5. The notion of process Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

6. The notion of process • A software lifecycle defines the skeletonand philosophyaccording to which the software process has to be carried out. • It does not prescribe a precise course of actions, an organization, tools and operating procedures, development policies and constraints. • Lifecycle is certainly an important starting point to define how software should be developed. • The notion of software process builds on the notion of lifecycle: • Provides a broad and comprehensive concept to frame and organize the different factors and issues related to software development activities. Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

7. The notion of process • A software process can be defined as: • “The coherent set of policies, organizational structures, technologies, procedures, and artifacts that are needed to conceive, develop, deploy, and maintain a software product”. • A software process exploits a number of contributions and concepts: • Development technology: • Technological support used in the process • Methods and techniques: • Guidelines on how to use technology and accomplish software development activities. • Organizational behaviour and social sciences: • The science of organizations and people. • Marketing and economy: • software must address real customers’ needs in specific market settings. • Increasing importance of the interplay of organizational, cultural, technological, and economic factors. Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

8. Process modeling and support • Software processes being complex entities, hence researchers have created a number of languages (Process Moddeling Languages, PMLs) and modeling formalisms: • PMLs make it possible to represent in a precise and comprehensive way a number of software process features: • Like Activities, role of People, tools to be used • Perspectives in process representation • People want to extract from a process model some answers for: • What is going to be done, who is going to do it, when and where it will be done, how and why will it be done. • Process modeling represents different perspectives • Functional: What (process elements, data flows) • Behavioral: When (process elements) How (process elements) • Organizational: Where and By Whom (process elements) Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

9. Process modeling and support • PMLs can be used for diffrent purpose: • Process understanding • Can be used to represent in a precise way how a process is structured and organized • Process design • Can be used to design a new process, by describing its structure and organization. • Training and education (on processes) • Precise description of the process can be useful to teach company procedures and operations to newly hired personnel. • Simulation and optimization • To evaluate possible problems, bottlenecks, and opportunities for improvement. • A modeling language can be graphical or textual • Graphical modeling languages: • use a diagram technique with named symbols that represent concepts and lines that connect the symbols and represent relationships and various other graphical notation to represent constraints. • Textual modeling languages • may use standardized keywords accompanied by parameters or natural language terms and phrases to make computer-interpretable expressions. • the Eiffel tower <is located in> Paris • Paris <is classified as a> city Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

10. Process improvement • Processes need to continuously undergo changes and refinements to increase their ability to deal with the requirements and expectations of the market and of the company stakeholders. • Hence, process need to be continuously assessed and improved. • Quality Models to evaluate the maturity of a software process: • CMM, ISO 9001, MBA (Malcolm Baldridge National Quality Award) • Defines the requirements of an ideal company, i.e., a reference model to be used in order to assess the state of a company and the degree of improvement achieved or to be achieved. • Improvement Methods to guide the process improvement activity: • IDEAL • SPICE (Software Process Improvement and Capability dEtermination) ISO/IEC 15504 • Improvement methods suggests the steps to be accomplished in order to improve the quality of a software process. • Improvement methods indicate how to carry out the “process of improving a process”. Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

11. Metrics and empirical studies • Definition of metrics and metrics selection techniques. • Indicators are needed that are able to quantify in a coherent and simple way the properties of the entities involved in software development • For Example • How can we evaluate the size and complexity of a Java program? Or • What is the productivity of a Java programmer? • Empirical methods: • An experimental approaches is needed to guide the evaluation of a specific process • how to carry out experiments. • Empirical results: • Metrics and empirical methods are the means that can be used to study a phenomenon. • Apply these means to understand and assess specific problems and settings, in order to learn something on the nature of software development processes. • “X is better than Y”. Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

12. Empirical studies are a means not an end • Sometimes, empirical studies are just statistical exercises. • Fishing for results. • What about • Significance?: • The results of most empirical studies appear to be not very significant. Even if it is certainly true that most empirical studies have the purpose of providing a formal and credible foundation for practitioners and researchers’ beliefs, often the added value of these experiments is limited. • What is the reader supposed to learn from this study? • External validity? • it is difficult to generalize the conclusions of the study outside the context where the study was carried out Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

13. Processes, eventually! • The consolidated experiences of researchers and practitioners have been instrumental to define and consolidate successful processes. • Two well-known examples: • Personal Software Process (PSP). • A collection of practices and techniques that are meant to guide the work of a software engineer. • Helps: • Improve their estimating and planning skills. • Make commitments they can keep. • Manage the quality of their projects. • Reduce the number of defects in their work. • Unified Software Process. (RUP) • A set of guidelines and process steps that should be followed to apply UML in the different stages of software development. Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

14. Problems • There are several problems. • "Most technologies developed by the software process community have not been transferred into industrial use. • "The number of papers on the software process modeling and technology presented at conferences and published in journals is decreasing. • "There is an increasing feeling that the community is stuck and unable to produce innovative and effective contributions. Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

15. Process Models in Software Engineering Walt Scacchi, Institute for Software Research, University of California,

16. Software Lifecycle • Classic software life cycle models usually include some version or subset of the following activities: • System Initiation/Planning: • where do systems come from? In most situations, new feasible systems replace or supplement existing information processing mechanisms whether they were previously automated, manual, or informal. • Requirement Analysis and Specification: • identifies the problems a new software system is suppose to solve, its operational capabilities, its desired performance characteristics, and the resource infrastructure needed to support system operation and maintenance. • Functional Specification or Prototyping: • identifies and potentially formalizes the objects of computation, their attributes and relationships, the operations that transform these objects, the constraints that restrict system behavior, and so forth. • Partition and Selection (Build vs. Buy vs. Reuse): • given requirements and functional specifications, divide the system into manageable pieces that denote logical subsystems, then determine whether new, existing, or reusable software systems correspond to the needed pieces. Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

17. Software Lifecycle • Partition and Selection (Build vs. Buy vs. Reuse): • given requirements and functional specifications, divide the system into manageable pieces that denote logical subsystems, then determine whether new, existing, or reusable software systems correspond to the needed pieces. • Architectural Design and Configuration Specification: • defines the interconnection and resource interfaces between system subsystems, components, and modules in ways suitable for their detailed design and overall configuration management. • Detailed Component Design Specification: • defines the procedural methods through which the data resources within the modules of a component are transformed from required inputs into provided outputs. • Component Implementation and Debugging: • codifies the preceding specifications into operational source code implementations and validates their basic operation. Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

18. Software Lifecycle • Software Integration and Testing: • affirms and sustains the overall integrity of the software system architectural configuration through verifying the consistency and completeness of implemented modules, verifying the resource interfaces and interconnections against their specifications, and validating the performance of the system and subsystems against their requirements. • Documentation Revision and System Delivery: • packaging and rationalizing recorded system development descriptions into systematic documents and user guides, all in a form suitable for dissemination and system support. • Deployment and Installation: • providing directions for installing the delivered software into the local computing environment, configuring operating systems parameters and user access privileges, and running diagnostic test cases to assure the viability of basic system operation. Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

19. Software Lifecycle • Training and Use: • providing system users with instructional aids and guidance for understanding the system's capabilities and limits in order to effectively use the system. • Software Maintenance: • sustaining the useful operation of a system in its host/target environment by providing requested functional enhancements, repairs, performance improvements, and conversions. Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

20. Software lifecycle model • A software lifecycle model is either a descriptive or prescriptive characterization of: • How software is or should be developed. • A Descriptive model: • Describes the history of how a particular software system was developed. • Descriptive models may be used as the basis for understanding and improving software development processes, or for building empirically grounded prescriptive models • A Prescriptive model: • Prescribes how a new software system should be developed. • Prescriptive models are used as guidelines or frameworks to organize and structure how software development activities should be performed, and in what order. Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

21. Characterization of SWLC Model • Two characterizations suggest that: • There are a variety of purposes for articulating software life cycle models • These characterizations serve as a: • Guideline to organize, plan, staff, budget, schedule and manage software project work over organizational time, space, and computing environments. • Prescriptive outline for what documents to produce for delivery to client. • Basis for determining what software engineering tools and methodologies will be most appropriate to support different life cycle activities. • Framework for analyzing or estimating patterns of resource allocation and consumption during the software life cycle (Boehm 1981) • Basis for conducting empirical studies to determine what affects software productivity, cost, and overall quality. Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

22. SWLC model & SW Process Model • In contrast to software life cycle models: • software process models often represent a networked sequence of activities, objects, transformations, and events that embody strategies for accomplishing software evolution. • Such models can be used to develop more precise and formalized descriptions of software life cycle activities. • Their power emerges from their utilization of a sufficiently rich notation, syntax, or semantics, often suitable for computational processing. Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

23. SW Process network • Software process networks can be viewed as representing multiple interconnected task chains. • Task chains represent a non-linear sequence of actions that structure and transform available computational objects (resources) into intermediate or finished products. • Non-linearity implies that the sequence of actions may be non-deterministic, iterative, accommodate multiple/parallel alternatives, as well as partially ordered to account for incremental progress. • Task chains can be employed to characterize either prescriptive or descriptive action sequences. • Prescriptive task chains are idealized plans of what actions should be accomplished, and in what order. • For example, a task chain for the activity of object-oriented software design might include the following task actions: • Develop an informal narrative specification of the system. • Identify the objects and their attributes. • Identify the operations on the objects. • Identify the interfaces between objects, attributes, or operations. • Implement the operations. Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

24. Traditional Software Life Cycle Models • Traditional models of software evolution have been in existence since long. • Waterfall & stepwise refinement • Available in almost all text Books • The incremental release model: • Closely related to industrial practices where it most often occurs • Military standards based models: • Used by government contractors. • Classic Software Life Cycle • Represented as a simple prescriptive waterfall software phase model, where software evolution proceeds through an orderly sequence of transitions from one phase to the next in order • Characterized as both poor descriptive and prescriptive models of how software development "in-the-small" or "in-the-large" can or should occur Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

25. Traditional Software Life Cycle Models • Stepwise Refinement • software systems are developed through the progressive refinement and enhancement of high-level system specifications into source code components • model has been most effective and widely applied in helping to teach individual programmers how to organize their software development work • Incremental Development and Release • Developing systems through incremental release requires first providing essential operating functions, then providing system users with improved and more capable versions of a system at regular intervals • combines the classic software life cycle with iterative enhancement Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

26. Industrial and Military Standards, and Capability Models • Industrial firms often uses variation of the classic model as the basis for standardizing their software development practices • Such standardization is often motivated by needs to simplify or eliminate complications that emerge during large software development or project management. • many government contractors organized their software development activities according to succession of military software standards such as: • MIL-STD-2167A, MIL-STD 498, and IEEE-STD-016. • ISO12207 (Moore 1997) • These standards are an outgrowth of the classic life cycle activities Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

27. Industrial and Military Standards, and Capability Models • Military software system are often constrained in ways not found in industrial or academic practice, including: • required use of military standard computing equipment (which is often technologically dated and possesses limited processing capabilities) • are embedded in larger systems (e.g., airplanes, submarines, missiles, command and control systems) which are mission-critical (i.e., those whose untimely failure could result in military disadvantage and/or life-threatening risks); • are developed under contract to private firms through cumbersome procurement and acquisition procedures that can be subject to public scrutiny and legislative intervention; and • many embedded software systems for the military are among the largest and most complex systems in the world Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

28. Software Product Development Models • Rapid Prototyping • Joint Application Development • Assembling Reusable Components • Application Generation • Software Documentation • Incremental Evolution, and Evolutionary Delivery Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

29. Software Production Process Models • Two kinds of software production process models: • non-operational and operational. • The difference between the two: • The operational models can be viewed as computational scripts or programs: • programs that implement a particular regimen of software engineering and development. • Spiral Model • The Continuous Transformation Models. • Non-operational models denote conceptual approaches: • Not yet been articulated in a form suitable for codification or automated processing. • A number of emerging trends exploit and extend the use of operational process models Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST

30. Software Engineering Processes Chapter 9 SWEBOK

31. Software Engineering Process Adv Software Engineering, MSCS 19, by Asst Prof Athar Mohsin, MCS-NUST