Software - Module 1 PDF

MODULE 1 Software (1) instructions (computer programs) that when executed provide desired features, function, and performance; (2) data structures that enable the programs to adequately manipulate information and (3) documentation that describes the operation and use of the programs...

MODULE 1 Software (1) instructions (computer programs) that when executed provide desired features, function, and performance; (2) data structures that enable the programs to adequately manipulate information and (3) documentation that describes the operation and use of the programs (Pressman, 2009). Types of Software 1. Application Software -The kind of software that people use to perform a general or specific task. Customize Software - software designed for a customer Packaged Software - the kind of “the shelf” program developed for sale to the public ○ Word Processing - allows a person to use a computer to create, edit, save, and print documents ○ Spreadsheets - allows a person to use rows, columns, and formulas to display, analyze and summarize data. ○ Database Manager - a program used to manage multiple data files. ○ Graphics - enables users to present information in the form of charts and graphs or to create complex freehand artwork ○ Communications - manages the transmission of data between computers over wired or wireless channels. 2. System software - Enables the application software to interact with the computer and help it manage resources. A collection of programs written to service programs. Operating System - manages the basic operations of the computers. Utility Programs - provides services not provided by other system software. Language Translators - software that translates a program written in a computer language by a computer programmer into a language that can be understand by the computer. Software Characteristics 1. Software is designed and built by software engineers.  2. Software is developed or engineered; it is not manufactured in the classical sense. 3. Software does not wear out, but it does deteriorate. 4. Although the industry is moving toward component-based construction, most software continues to be custom-built. 5. Software is both a product and a vehicle for developing a product. Software Applications Domains 1. System Software - a collection of programs written to service other programs. Some system software (e.g., compilers, editors, and file management utilities) processes complex, but determinate,4 information structures. 2. Application Software - stand-alone programs that solve a specific business need. Applications in this area process business or technical data in a way that facilitates business operations or management/technical decision making 3. Engineering/scientific software - has been characterized by “number crunching” algorithms. 4. Embedded Software - resides within a product or system and is used to implement and control features and functions for the end user and for the system itself. 5. Product-line-software - designed to provide a specific capability for use by many different customers. 6. Web Application - called “WebApps” this network-centric software category spans a wide array of applications. 7. Artificial Intelligence Software - makes use of nonnumerical algorithms to solve complex problems that are not amenable to computation or straightforward analysis. 8. Open-world computing - the rapid growth of wireless networking may soon lead to true pervasive, distributed computing. 9. Netsourcing - the World Wide Web is rapidly becoming a computing engine as well as a content provider. The challenge for software engineers is to architect simple (e.g., personal financial planning) and sophisticated applications that provide a benefit to targeted end-user markets worldwide. 10. Open source - a growing trend that results in the distribution of source code for systems applications (e.g., operating systems, databases, and development environments) so that many people can contribute to its development. Legacy of Software 1. software must be adapted to meet the needs of new computing environments or technology. 2. software must be enhanced to implement new business requirements.  3. software must be extended to make it interoperable with other more modern systems or databases. 4. software must be re-architected to make it viable within a network environment. Overview of Software Engineering Software has become deeply embedded virtually in every aspect of our lives, and as a consequence, the number of people who have an interest in the features and functions provided by a specific application has grown dramatically. What is Software Engineering? the establishment and use of sound engineering principles in order to obtain economic software that is reliable and works efficiently on real machines. (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1). Software engineering is a layered technology. The Software Process Communication. Before any technical work can commence, it is critically important to communicate and collaborate with the customer and other stakeholders. The intent is to understand stakeholders’ objectives for the project and to gather requirements that help define software features and functions. Planning. Any complicated journey can be simplified if a map exists. It defines the software engineering work by describing the technical tasks to be conducted, the risks that are likely, the resources that will be required, the work products to be produced, and a work schedule. Modeling. You refine the sketch into greater and greater detail in an effort to better understand the problem and how you’re going to solve it. A software engineer does the same thing by creating models to better understand software requirements and the design that will achieve those requirements. Construction. This activity combines code generation (either manual or automated) and the testing that is required to uncover errors in the code. Deployment. The software (as a complete entity or as a partially completed increment) is delivered to the customer who evaluates the delivered product and provides feedback based on the evaluation. Software engineering process framework activities are complemented by a number of umbrella activities. In general, umbrella activities are applied throughout a software project and help a software team manage and control progress, quality, change, and risk. Typical umbrella activities include: Software project tracking and control—allows the software team to assess progress against the project plan and take any necessary action to maintain the schedule. Risk management—assesses risks that may affect the outcome of the project or the quality of the product. Software quality assurance—defines and conducts the activities required to ensure software quality. Technical reviews—assesses software engineering work products in an effort to uncover and remove errors before they are propagated to the next activity. Measurement—defines and collects process, project, and product measures that assist the team in delivering software that meets stakeholders’ needs; can be used in conjunction with all other framework and umbrella activities. Software configuration management—manages the effects of change throughout the software process. Reusability management—defines criteria for work product reuse (including software components) and establishes mechanisms to achieve reusable components. Work product preparation and production—encompasses the activities required to create work products such as models, documents, logs, forms, and lists. Adapting a Process Model A process adopted for one project might be significantly different than a process adopted for another project. Among the differences are: 1. the overall flow of activities, actions, and tasks and the interdependencies among them 2. the degree to which actions and tasks are defined within each framework activity 3. the degree to which work products are identified and required 4. the manner which quality assurance activities are applied  5. the manner in which project tracking and control activities are applied 6. the overall degree of detail and rigor with which the process is described 7. the degree to which the customer and other stakeholders are involved with the project 8. the level of autonomy given to the software team 9. the degree to which team organization and roles are prescribed Software Engineering Practices Generic framework activities—communication, planning, modeling, construction, and deployment—and umbrella activities establish a skeleton architecture for software engineering work Polya suggests: A. Understand the problem (communication and analysis). B. Plan a solution (modeling and software design). C. Carry out the plan (code generation). D. Examine the result for accuracy (testing and quality assurance). General Principles David Hooker [Hoo96] has proposed seven principles that focus on software engineering practicie as a whole. They are reproduced in the following paragraphs: The First Principle: The Reason It All Exists A software system exists for one reason: to provide value to its users. All decisions should be made with this in mind. Before specifying a system requirement, before noting a piece of system functionality, before determining the hardware platforms or development processes, ask yourself questions such as: “Does this add real value to the system?” If the answer is “no,” don’t do it. The Second Principle: KISS (Keep It Simple, Stupid!) Software design is not a haphazard process. There are many factors to consider in any design effort. All design should be as simple as possible, but no simpler. The Third Principle: Maintain the Vision A clear vision is essential to the success of a software project. Having an empowered architect who can hold the vision and enforce compliance helps ensure a very successful software project. The Fourth Principle: What You Produce, Others Will Consume Specify with an eye to the users. Design, keeping the implementers in mind. Code with concern for those that must maintain and extend the system. Someone may have to debug the code you write, and that makes them a user of your code. Making their job easier adds value to the system. The Fifth Principle: Be Open to the Future A system with a long lifetime has more value.These systems must be ready to adapt to these and other changes. Systems that do this successfully are those that have been designed this way from the start. Never design yourself into a corner. Always ask “what if,” and prepare for all possible answers by creating systems. The Sixth Principle: Plan Ahead for Reuse Reuse saves time and effort. Achieving a high level of reuse is arguably the hardest goal to accomplish in developing a software system. The reuse of code and designs has been proclaimed as a major benefit of using object-oriented technologies. However, the return on this investment is not automatic. To leverage the reuse possibilities that object-oriented [or conventional] programming provides requires forethought and planning. There are many techniques to realize reuse at every level of the system development process.... Planning ahead for reuse reduces the cost and increases the value of both the reusable components and the systems into which they are incorporated. The Seventh principle: Think! This last principle is probably the most overlooked. Placing clear, complete thought before action almost always produces better results. When you think about something, you are more likely to do it right. You also gain knowledge about how to do it right again. If you do think about something and still do it wrong, it becomes a valuable experience. A side effect of thinking is learning to recognize when you don’t know something, at which point you can research the answer. When clear thought has gone into a system, value comes out. Applying the first six principles requires intense thought, for which the potential rewards are enormous. Software Myths Software myths—erroneous beliefs about software and the process that is used to build it—can be traced to the earliest days of computing. Myths have a number of attributes that make them insidious. For instance, they appear to be reasonable statements of fact (sometimes containing elements of truth), they have an intuitive feel, and they are often promulgated by experienced practitioners who “know the score.” Today, most knowledgeable software engineering professionals recognize myths for what they are—misleading attitudes that have caused serious problems for managers and practitioners alike. However, old attitudes and habits are difficult to modify, and remnants of software myths remain. Management Myths Managers with software responsibility, like managers in most disciplines, are often under pressure to maintain budgets, keep schedules from slipping, and improve quality. Like a drowning person who grasps at a straw, a software manager often grasps at belief in a software myth, if that belief will lessen the pressure (even temporarily). Myth: We already have a book that’s full of standards and procedures for building software. Won’t that provide my people with everything they need to know? Reality: The book of standards may very well exist, but is it used? Are software practitioners aware of its existence? Does it reflect modern software engineering practice? Is it complete? Is it adaptable? Is it streamlined to improve time-to-delivery while still maintaining a focus on quality? In many cases, the answer to all of these questions is “no.” Myth: If we get behind schedule, we can add more programmers and catch up (sometimes called the “Mongolian horde” concept). Reality: Software development is not a mechanistic process like manufacturing. In the words of Brooks [Bro95]: “adding people to a late software project makes it later.” At first, this statement may seem counterintuitive. However, as new people are added, people who were working must spend time educating the newcomers, thereby reducing the amount of time spent on productive development efforts. People can be added but only in a planned and well-coordinated manner. Myth: If I decide to outsource the software project to a third party, I can just relax and let that firm build it. Reality: If an organization does not understand how to manage and control software projects internally, it will invariably struggle when it outsources software projects. Customer Myths A customer who requests computer software may be a person at the next desk, a technical group down the hall, the marketing/sales department, or an outside company that has requested software under contract. In many cases, the customer believes myths about software because software managers and practitioners do little to correct misinformation. Myths lead to false expectations (by the customer) and, ultimately, dissatisfaction with the developer. Myth: A general statement of objectives is sufficient to begin writing programs—we can fill in the details later. Reality: Although a comprehensive and stable statement of requirements is not always possible, an ambiguous “statement of objectives” is a recipe for disaster. Unambiguous requirements (usually derived iteratively) are developed only through effective and continuous communication between customer and developer. Myth: Software requirements continually change, but change can be easily accommodated because software is flexible. Reality: It is true that software requirements change, but the impact of change varies with the time at which it is introduced. When requirements changes are requested early (before design or code has been started), the cost impact is relatively small. However, as time passes, the cost impact grows rapidly—resources have been committed, a design framework has been established, and change can cause upheaval that requires additional resources and major design modification. Practitioner’s Myths Myths that are still believed by software practitioners have been fostered by over 50 years of programming culture. During the early days, programming was viewed as an art form. Old ways and attitudes die hard. Myth: Once we write the program and get it to work, our job is done. Reality: Someone once said that “the sooner you begin ‘writing code,’ the longer it’ll take you to get done.” Industry data indicate that between 60 and 80 percent of all effort expended on software will be expended after it is delivered to the customer for the first time. Myth: Until I get the program “running” I have no way of assessing its quality. Reality: One of the most effective software quality assurance mechanisms can be applied from the inception of a project—the technical review. Software reviews are a “quality filter” that have been found to be more effective than testing for finding certain classes of software defects. Myth: The only deliverable work product for a successful project is the working program. Reality: A working program is only one part of a software configuration that includes many elements. A variety of work products (e.g., models, documents, plans) provide a foundation for successful engineering and, more important, guidance for software support. Myth: Software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down. Reality: Software engineering is not about creating documents. It is about creating a quality product. Better quality leads to reduced rework. And reduced rework results in faster delivery times. MODULE 2 Key Concepts What is it? Before you begin any technical work, it’s a good idea to create a set of requirements for any engineering tasks. These tasks lead to an understanding of what the business impact of the software will be, what the customer wants, and how end users will interact with the software. Who does it? Software engineers (sometimes referred to as system engineers or “analysts” in the IT world) and other project stakeholders (managers, customers, and end users) all participate in requirements engineering. Why is it important? Designing and building an elegant computer program that solves the wrong problem serves no one’s needs. That’s why it’s important to understand what the customer wants before you begin to design and build a computer-based system. What are the steps? Requirements engineering begins with inception (a task that defines the scope and nature of the problem to be solved). It moves onward to elicitation (a task that helps stakeholders defi ne what is required), and then elaboration (where basic requirements are refi ned and modified). As stakeholders define the problem, negotiation occurs (what are the priorities, what is essential, when is it required?) Finally, the problem is specified in some manner and then reviewed or validated to ensure that your understanding of the problem and the stakeholders’ understanding of the problem coincide. What is the work product? The intent of requirements engineering is to provide all parties with a written understanding of the problem. This can be achieved though a number of work products: usage scenarios, functions and features lists, requirements models, or a specifi cation. How do I ensure that I’ve done it right? Requirements engineering work products are reviewed with stakeholders to ensure that what you have learned is what they really meant. A word of warning: Even after all parties agree, things will change, and they will continue to change throughout the project. Requirements Engineering Inception. How does a software project get started? Is there a single event that becomes the catalyst for a new computer-based system or product, or does the need evolve over time? There are no definitive answers to these questions. In some cases, a casual conversation is all that is needed to precipitate a major software engineering effort. But in general, most projects begin when a business need is identified or a potential new market or service is discovered. Stakeholders from the business community (e.g., business managers, marketing people, product managers) define a business case for the idea, try to identify the breadth and depth of the market, do a rough feasibility analysis, and identify a working description of the project’s scope. All of this information is subject to change, but it is sufficient to precipitate discussions with the software engineering organization. 2 At project inception, 3 you establish a basic understanding of the problem, the people who want a solution, the nature of the solution that is desired, and the effectiveness of preliminary communication and collaboration between the other stakeholders and the software team. Elicitation. It certainly seems simple enough—ask the customer, the users, and thers what the objectives for the system or product are, what is to be accomplished, how the system or product fits into the needs of the business, and finally, how the system or product is to be used on a day-to-day basis. Elaboration. The information obtained from the customer during inception and elicitation is expanded and refined during elaboration. Negotiation. It isn’t unusual for customers and users to ask for more than can be achieved, given limited business resources. It’s also relatively common for different customers or users to propose confl icting requirements, arguing that their version is “essential for our special needs.” You have to reconcile these conflicts through a process of negotiation. Customers, users, and other stakeholders are asked to rank requirements and then discuss conflicts in priority. Specification. In the context of computer-based systems (and software), the term specification means different things to different people. A specification can be a written document, a set of graphical models, a formal mathematical model, a collection of usage scenarios, a prototype, or any combination of these. Validation. The work products produced as a consequence of requirements engineering are assessed for quality during a validation step. Requirements validation examines the specification to ensure that all software requirements have been stated unambiguously. Requirements management. Requirements for computer-based systems change, and the desire to change requirements persists throughout the life of the system. Requirements management is a set of activities that help the project team identify, control, and track requirements and changes to requirements at any time as the project proceeds. Many of these activities are identical to the software confi guration management (SCM) techniques Establishing the Groundwork 8.2.1 Identifying Stakeholders Sommerville and Sawyer [Som97] define a stakeholder as “anyone who benefits in a direct or indirect way from the system which is being developed.” 8.2.2 Recognizing Multiple Viewpoints Because many different stakeholders exist, the requirements of the system will be explored from many different points of view. As information from multiple viewpoints is collected, emerging requirements may be inconsistent or may conflict with one another. You should categorize all stakeholder information (including inconsistent and conflicting requirements) in a way that will allow decision-makers to choose an internally consistent set of requirements for the system. 8.2.3 Working toward Collaboration If five stakeholders are involved in a software project, you may have five (or more) different opinions about the proper set of requirements. Throughout earlier chapters, we have noted that customers (and other stakeholders) should collaborate among themselves (avoiding petty turf battles) and with software engineering practitioners if a successful system is to result. But how is this collaboration accomplished? The job of a requirements engineer is to identify areas of commonality (i.e., requirements on which all stakeholders agree) and areas of conflict or inconsistency (i.e., requirements that are desired by one stakeholder but confl ict with the needs of another stakeholder). 8.2.4 Asking the First Questions Questions asked at the inception of the project should be “context free” [Gau89]. The first set of context-free questions focuses on the customer and other stakeholders, the overall project goals and benefi ts. For example, you might ask: Who is behind the request for this work? Who will use the solution? What will be the economic benefit of a successful solution? Is there another source for the solution that you need? These questions help to identify all stakeholders who will have interest in the software to be built. In addition, the questions identify the measurable benefit of a successful implementation and possible alternatives to custom software development. The next set of questions enables you to gain a better understanding of the problem and allows the customer to voice his or her perceptions about a solution: How would you characterize “good” output that would be generated by a successful solution? What problem(s) will this solution address? Can you show me (or describe) the business environment in which the solution will be used?  Will special performance issues or constraints affect the way the solution is approached? The final set of questions focuses on the effectiveness of the communication activity itself. Gause and Weinberg [Gau89] call these “meta-questions” and propose the following (abbreviated) list: Are you the right person to answer these questions? Are your answers “official”? Are my questions relevant to the problem that you have? Am I asking too many questions? Can anyone else provide additional information? Should I be asking you anything else? 8.2.5 Nonfunctional Requirements A nonfunctional requirement (NFR) can be described as a quality attribute, a performance attribute, a security attribute, or a general constraint on a system. These are often not easy for stakeholders to articulate. Chung [Chu09] suggests that there is a lopsided emphasis on functionality of the software, yet the software may not be useful or usable without the necessary non-functional characteristics. 8.2.6 Traceability Traceability is a software engineering term that refers to documented links between software engineering work products (e.g., requirements and test cases). A traceability matrix allows a requirements engineer to represent the relationship between requirements and other software engineering work products. Eliciting Requirements 8.3.1 Collaborative Requirements Gathering Many different approaches to collaborative requirements gathering have been proposed. Each makes use of a slightly different scenario, but all apply some variation on the following basic guidelines: Meetings (either real or virtual) are conducted and attended by both software engineers and other stakeholders. Rules for preparation and participation are established. An agenda is suggested that is formal enough to cover all importantpoints but informal enough to encourage the free fl ow of ideas. A “facilitator” (can be a customer, a developer, or an outsider) controls the meeting. A “definition mechanism” (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room, or virtual forum) is used. The goal is to identify the problem, propose elements of the solution, negotiate different approaches, and specify a preliminary set of solution requirements. 8.3.4 Elicitation Work Products The work products produced as a consequence of requirements elicitation will vary depending on the size of the system or product to be built. For most systems, the work products include: (1) a statement of need and feasibility, (2) a bounded statement of scope for the system or product, (3) a list of customers, users, and other stakeholders who participated in requirements elicitation, (4) a description of the system’s technical environment, (5) a list of requirements (preferably organized by function) and the domain constraints that applies to each, (6) aset of usage scenarios that provide insight into the use of the system or product under different operating conditions, and (7) any prototypes developed to better defi ne requirements. Each of these work products is reviewed by all people who have participated in requirements elicitation. 8.3.5 Agile Requirements Elicitation Within the context of an agile process, requirements are elicited by asking all stakeholders to create user stories. Each user story describes a simple system requirement written from the user’s perspective. User stories can be written on small note cards, making it easy for developers to select and manage a subset of requirements to implement for the next product increment. Negotiating Requirements In an ideal requirements engineering context, the inception, elicitation, and elaboration tasks determine customer requirements in sufficient detail to proceed to subsequent software engineering activities. Unfortunately, this rarely happens. In reality, you may have to enter into a negotiation with one or more stakeholders. In most cases, stakeholders are asked to balance functionality, performance, and other product or system characteristics against cost and time-to-market. Rather than a single customer communication activity, the following activities are defined: 1. Identification of the system or subsystem’s key stakeholders. 2. Determination of the stakeholders’ “win conditions.” 3. Negotiation of the stakeholders’ win conditions to reconcile them into a set of win-win conditions for all concerned (including the software team). Successful completion of these initial steps achieves a win-win result, which becomes the key criterion for proceeding to subsequent software engineering activities. 8.7 REQUIREMENTS MONITORING Today, incremental development is commonplace. This means that use cases evolve, new test cases are developed for each new software increment, and continuous integration of source code occurs throughout a project. Requirements monitoring can be extremely useful when incremental development is used. It encompasses five tasks: (1) distributed debugging uncovers errors and determines their cause, (2) run-time verification determines whether software matchesits specification, (3) run-time validation assesses whether the evolving softwar meets user goals, (4) business activity monitoring evaluates whether a system satisfies business goals, and (5) evolution and codesign provides information to stakeholders as the system evolves. 8.8 VALIDATING REQUIREMENTS As each element of the requirements model is created, it is examined for inconsistency, comissions, and ambiguity. The requirements represented by the model are prioritized by stakeholders and grouped within requirements packages that will be implemented as software increments. A review of the requirements model addresses the following questions: Is each requirement consistent with the overall objectives for the system or product? Have all requirements been specified at the proper level of abstraction? -That is, do some requirements provide a level of technical detail that is inappropriate at this stage? Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system? Is each requirement bounded and unambiguous? Does each requirement have attribution? That is, is a source (generally, a specifi c individual) noted for each requirement? Do any requirements confl ict with other requirements? Is each requirement achievable in the technical environment that will house the system or product? Is each requirement testable, once implemented? Does the requirements model properly refl ect the information, function, and behavior of the system to be built? Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system? Have requirements patterns been used to simplify the requirements model? Have all patterns been properly validated? Are all patterns consistent with customer requirements? These and other questions should be asked and answered to ensure that the requirements model is an accurate reflection of stakeholder needs and that it provides a solid foundation for design. Lesson 2 Discussion 1 Key Concepts What is it? Although many of us (in our darker moments) take Dilbert’s view of “management,” it remains a very necessary activity when computer-based systems and products are built. Project management involves the planning, monitoring, and control of the people, process, and events that occur as software evolves from a preliminary concept to full operational deployment. Who does it? Everyone “manages” to some extent, but the scope of management activities varies among people involved in a software project. A software engineer manages her day-to-day activities, planning, monitoring, and controlling technical tasks. Project managers plan, monitor, and control the work of a team of software engineers. Senior managers coordinate the interface between the business and software professionals. Why is it important? Building computer software is a complex undertaking, particularly if it involves many people working over a relatively long time. That’s why software projects need to be managed. What are the steps? Understand the four Ps—people, product, process, and project. People must be organized to perform software work effectively. Communication with the customer and other stakeholders must occur so that product scope and requirements are understood. What is the work product? A project plan is produced as management activities commence. The plan defines the process and tasks to be conducted, the people who will do the work, and the mechanisms for assessing risks, controlling change, and evaluating quality. How do I ensure that I’ve done it right? You’re never completely sure that the project plan is right until you’ve delivered a high-quality product on time and within budget. Management Spectrum 31.1.1 The People The cultivation of motivated, highly skilled software people has been discussed since the 1960s. In fact, the “people factor” is so important that the Software Engineering Institute has developed a People Capability Maturity Model (People-CMM), in recognition of the fact that “every organization needs to continually improve its ability to attract, develop, motivate, organize, and retain the workforce needed to accomplish its strategic business objectives” [Cur01]. 31.1.2 The Product Before a project can be planned, product objectives and scope should be established, alternative solutions should be considered, and technical and management constraints should be identified. Without this information, it is impossible to define reasonable (and accurate) estimates of the cost, an effective assessment of risk, a realistic breakdown of project tasks, or a manageable project schedule that provides a meaningful indication of progress. Once the product objectives and scope are understood, alternative solutions are considered. Although very little detail is discussed, the alternatives enable managers and practitioners to select a “best” approach, given the constraints imposed by delivery deadlines, budgetary restrictions, personnel availability, technical interfaces, and myriad other factors. 31.1.3 The Process A software process (Chapters 3–5) provides the framework from which a comprehensive plan for software development can be established. A small number of framework activities are applicable to all software projects, regardless of their size or complexity. A number of different task sets—tasks, milestones, work products, and quality assurance points—enable the framework activities to be adapted to the characteristics of the software project and the requirements of the project team. Finally, umbrella activities—such as software quality assurance, software confi guration management, and measurement—overlay the process model. Umbrella activities are independent of any one framework activity and occur throughout the process. 31.1.4 The Project We conduct planned and controlled software projects for one primary reason—it is the only known way to manage complexity. And yet, software teams still struggle. To avoid project failure, a software project manager and the software engineers who build the product must avoid a set of common warning signs, understand the critical success factors that lead to good project management, and develop a commonsense approach for planning, monitoring, and controlling the project. Each of these issues is discussed in Section 31.5 and in the chapters that follow. 31.2 PEOPLE People build computer software, and projects succeed because well-trained, motivated people get things done. 31.2.1 The Stakeholders The software process (and every software project) is populated by stakeholders who can be categorized into one of five constituencies: 1. Senior managers who define the business issues that often have a significant infl uence on the project. 2. Project (technical) managers who must plan, motivate, organize, and control the practitioners who do software work. 3. Practitioners who deliver the technical skills that are necessary to engineer a product or application. 4. Customers who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome. 5. End users who interact with the software once it is released for production use. Every software project is populated by people who fall within this taxonomy. To be effective, the project team must be organized in a way that maximizes each person’s skills and abilities. And that’s the job of the team leader. 31.2.2 Team Leaders Project management is a people-intensive activity, and for this reason, competent practitioners often make poor team leaders. They simply don’t have the right mix of people skills. In an excellent book of technical leadership, Jerry Weinberg [Wei86] suggests an MOI model of leadership Motivation. The ability to encourage (by “push or pull”) technical people to produce to their best ability. Organization. The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product. Ideas or innovation. The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application. Weinberg suggests that successful project leaders apply a problem-solving management style. That is, a software project manager should concentrate on understanding the problem to be solved, managing the flow of ideas, and at the same time, letting everyone on the team know (by words and, far more important, by actions) that quality counts and that it will not be compromised. Problem solving. An effective software project manager can diagnose the technical and organizational issues that are most relevant, systematically structure a solution or properly motivate other practitioners to develop the solution, apply lessons learned from past projects to new situations, and remain flexible enough to change direction if initial attempts at problem solution are fruitless. Managerial identity. A good project manager must take charge of the project. She must have the confidence to assume control when necessary and the assurance to allow good technical people to follow their instincts. A competent manager must reward initiative and accomplishment to optimize the productivity of a project team. She must demonstrate through her own actions that controlled risk taking will not be punished. Influence and team building. An effective project manager must be able to “read” people; she must be able to understand verbal and nonverbal signals and react to the needs of the people sending these signals. The manager must remain under control in high-stress situations. 31.2.3 The Software Team There are almost as many human organizational structures for software development as there are organizations that develop software. For better or worse, organizational structure cannot be easily modified. Concern with the practical and political consequences of organizational change are not within the software project manager’s scope of responsibility. However, the organization of the people directly involved in a new software project is within the project manager’s purview. The “best” team structure depends on the management style of your organization, the number of people who will populate the team and their skill levels, and the overall problem difficulty. Mantei [Man81] describes seven project factors that should be considered when planning the structure of software engineering teams: (1) difficulty of the problem to be solved; (2) “size” of the resultant program(s) in lines of code or function points; (3) time that the team will stay together (team lifetime); (4) degree to which the problem can be modularized; (5) quality and reliability of the system to be built; (6) rigidity of the delivery date, and (7) degree of sociability (communication) required for the project. Paradigms 1. A closed paradigm structures a team along a traditional hierarchy of authority. Such teams can work well when producing software that is quite similar to past efforts, but they will be less likely to be innovative when working within the closed paradigm. 2. A random paradigm structures a team loosely and depends on individual initiative of the team members. When innovation or technological breakthrough is required, teams following the random paradigm will excel. But such teams may struggle when “orderly performance” is required. 3. An open paradigm attempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm. Work is performed collaboratively, with heavy communication and consensus-based decision making the trademarks of open paradigm teams. Open paradigm team structures are well suited to the solution of complex problems but may not perform as effi ciently as other teams 4. A synchronous paradigm relies on the natural compartmentalization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves. 31.3 THE PRODUCT 31.3.1 Software Scope The first software project management activity is the determination of software scope. Scope is defined by answering the following questions: Context. How does the software to be built fit into a larger system, product, or business context, and what constraints are imposed as a result of the context? Information objectives. What customer-visible data objects are produced as output from the software? What data objects are required for input? Function and performance. What function does the software perform to transform input data into output? Are any special performance characteristics to be addressed? 31.3.2 Problem Decomposition Problem decomposition, sometimes called partitioning or problem elaboration, is an activity that sits at the core of software requirements analysis. During the scoping activity no attempt is made to fully decompose the problem. Rather, decomposition is applied in two major areas: (1) the functionality and content (information) that must be delivered and (2) the process that will be used to deliver it. 31.4 THE PROCESS Your team must decide which process model is most appropriate for (1) the customers who have requested the product and the people who will do the work, (2) the characteristics of the product itself, and (3) the project environment in which the software team works. 31.4.1 Melding the Product and the Process Project planning begins with the melding of the product and the process. Each function to be engineered by your team must pass through the set of framework activities that have been defined for your software organization. 31.5 THE PROJECT In order to manage a successful software project, you have to understand what can go wrong so that problems can be avoided. Reel [Ree99] suggests a five-part commonsense approach to software projects: 1. Start on the right foot. 2. Maintain momentum. 3. Track progress. 4. Make smart decisions. 5. Conduct a postmortem analysis. PM3 Lesson 3 - Key Concepts What is it? Software process and project metrics are quantitative measures that enable you to gain insight into the efficacy of the software process and the projects that are conducted using the process as a framework. Who does it? Software metrics are analyzed and assessed by software managers. Measures are often collected by software engineers. Why is it important? If you don’t measure, judgment can be based only on subjective evaluation. With measurement, trends (either good or bad) can be spotted, better estimates can be made, and true improvement can be accomplished over time. What are the steps? Begin by defining a limited set of process, project, and product measures that are easy to collect. These measures are often normalized using either size- or function-oriented metrics. The result is analyzed and compared to past averages for similar projects performed within the organization. Trends are assessed and conclusions are generated. What is the work product? A set of software metrics that provides insight into the process and understanding of the project. How do I ensure that I’ve done it right? By applying a consistent, yet simple measurement scheme that is never to be used to assess, reward, or punish individual performance. 32.1 METRICS IN THE PROCESS AND PROJECT DOMAINS 32.1.1 Process Metrics and Software Process Improvement The only rational way to improve any process is to measure specific attributes of the process, develop a set of meaningful metrics based on these attributes, and then use the metrics to provide indicators that will lead to a strategy for improvement. Public metrics generally assimilate information that originally was private to individuals and teams. Project-level defect rates (absolutely not attributed to an individual), effort, calendar times, and related data are collected and evaluated in an attempt to uncover indicators that can improve organizational process performance. 32.1.2 Project Metrics Unlike software process metrics that are used for strategic purposes, software project measures are tactical. Classification of Software Metrics Software metrics can be classified into two types as follows: 1. Product Metrics: These are the measures of various characteristics of the software product. The two important software characteristics are: 1. Size and complexity of software. 2. Quality and reliability of software. These metrics can be computed for different stages of SDLC. 2. Process Metrics: These are the measures of various characteristics of the software development process. Types of Metrics Internal metrics: Internal metrics are the metrics used for measuring properties that are viewed to be of greater importance to a software developer. External metrics: External metrics are the metrics used for measuring properties that are viewed to be of greater importance to the user. Hybrid metrics: Hybrid metrics are the metrics that combine product, process, and resource metrics. Project metrics: Project metrics are the metrics used by the project manager to check the project's progress. Advantage of Software Metrics 1. Comparative study of various design methodology of software systems. 2. For analysis, comparison, and critical study of different programming language concerning their characteristics. 3. In comparing and evaluating the capabilities and productivity of people involved in software development. 4. In the preparation of software quality specifications. 5. In the verification of compliance of software systems requirements and specifications. 6. In making inference about the effort to be put in the design and development of the software systems. 7. In getting an idea about the complexity of the code. 25.3 So f t wa r e Sc o p e a n d Fe a s i b ili t y Software scope describes the functions and features that are to be delivered to end users; the data that are input and output; the “content” that is presented to users as a consequence of using the software; and the performance, constraints, interfaces, and reliability that bound the system. 25.4 Re s o u rc e s Once the scope is defined, you must estimate the resources required to build software that will implement the set of use cases that describe software features and functions. 25.4.1 Human Resources The planner begins by evaluating the software scope and selecting the skills required to complete development. Both organizational positions (e.g., manager, senior software engineer) and specialties (e.g., telecommunications, database, e-commerce) are specified. For relatively small projects (a few person-months), a single individual may perform all software engineering tasks, consulting with specialists as required. For larger projects, the software team may be geographically dispersed across a number of different locations. MODULE 3 Process models were originally proposed to bring order to the chaos of software development. A process model provides a specific roadmap for software engineering work. It defines the flow of all activities, actions, and tasks, the degree of iteration, the work products, and the organization of the work that must be done. Software engineers and their managers adapt a process model to their needs and then follow it. In addition, the people who have requested the software have a role to play in the process of defining, building, and testing it. It provides stability, control, and organization to an activity that can if left uncontrolled, become quite chaotic. Prescriptive Process Models It strives for structure and order in software development. Activities and tasks occur sequentially with defined guidelines for progress. The Waterfall Model ○ There are times when the requirements for a problem are well understood— when workflows from communication through deployment in a reasonably linear fashion. ○ There is sometimes encountered when well-defined adaptations or enhancements to an existing system must be made (e.g., an adaptation to accounting software that has been mandated because of changes to government regulations). ○ The waterfall model, sometimes called the classic life cycle, suggests a systematic, sequential approach 2 to software development that begins with customer specification of requirements and progresses through planning, modeling, construction, and deployment, culminating in ongoing support of the completed software ○ The V-model A variation in the representation of the waterfall model is called the V-model. V-model depicts the relationship of quality assurance actions to the actions associated with communication, modeling, and early construction activities.  Incremental Process Models ○ When an incremental model is used, the first increment is often a core product. That is, basic requirements are addressed but many supplementary features (some known, others unknown) remain undelivered. ○ The core product is used by the customer (or undergoes detailed evaluation). Evolutionary Process Models ○ Evolutionary models are iterative. ○ They are characterized in a manner that enables you to develop increasingly more complete versions of the software. Prototyping ○ It can be used as a stand-alone process model, ○ It is planned quickly, and modeling (in the form of a “quick design”) occurs. ○ It is deployed and evaluated by stakeholders, who provide feedback that is used to further refine requirements. The Spiral Model ○ It is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model. ○ It is a risk-driven process model generator that is used to guide multi-stakeholder concurrent engineering of software-intensive systems. ○ It is divided into a set of framework activities defined by the software engineering team. Concurrent Models ○ The concurrent development model, sometimes called concurrent engineering, allows a software team to represent iterative and concurrent elements of any of the process models described in this chapter. Specialized Models Specialized process models take on many of the characteristics of one or more of the traditional models presented in the preceding sections. Component-Based Development ○ It is software components, developed by vendors who offer them as products, provide targeted functionality with well-defined interfaces that enable the component to be integrated into the software that is to be built. ○ It incorporates many of the characteristics of the spiral model. The Formal Methods Model ○ It encompasses a set of activities that leads to formal mathematical specification of computer software. ○ enable you to specify, develop, and verify a computer-based system by applying a rigorous, mathematical notation. Aspect-Oriented Software Development ○ often referred to as aspect-oriented programming (AOP) or aspect-oriented component engineering (AOCE) [Gru02], is a relatively new software engineering paradigm that provides a process The Unified Process is an attempt to draw on the best features and characteristics of traditional software process models, but characterize them in a way that implements many of the best principles of agile software development. recognizes the importance of customer communication and streamlined methods for describing the customer’s view of a system (the use case). A Brief History ○ During the early 1990s James Rumbaugh [Rum91], Grady Booch [Boo94], and Ivar Jacobson [Jac92] began working on a “unified method” that would combine the best features of each of their individual object-oriented analysis and design methods and adopt additional features proposed by other experts (e.g., [Wir90]) in object-oriented modeling. ○ UML—a unified modeling language that contains a robust notation for the modeling and development of object-oriented systems. Phases of the Unified Process ○ The inception phase of the UP encompasses both customer communication and planning activities. By collaborating with stakeholders, business requirements for the software are identified; a rough architecture for the system is proposed; and a plan for the iterative, incremental nature of the ensuing project is developed.  ○ The elaboration phase encompasses the communication and modeling activities of the generic process model ( Figure 4.7 ). Elaboration refines and expands the preliminary use cases that were developed as part of the inception phase and expands the architectural representation to include five different views of the software—the use case model, the analysis model, the design model, the implementation model, and the deployment model. In some cases, elaboration creates an “executable architectural baseline” [Arl02] that represents a “first cut” executable system. ○ The construction phase of the UP is identical to the construction activity defined for the generic software process. Using the architectural model as input, the construction phase develops or acquires the software components that will make each use case operational for end users. ○ The transition phase of the UP encompasses the latter stages of the generic construction activity and the first part of the generic deployment (delivery and feedback) activity. ○ The production phase of the UP coincides with the deployment activity of the generic process. During this phase, the ongoing use of the software is monitored, support for the operating environment (infrastructure) is provided, and defect reports and requests for changes are submitted and evaluated. Personal and Team Process Models ○ Personal Software Process emphasizes personal measurement of both the work product that is produced and the resultant quality of the work product. In addition, PSP makes the practitioner responsible for project planning (e.g., estimating and scheduling) and empowers the practitioner to control the quality of all software work products that are developed. The PSP model defines five framework activities: Planning. This activity isolates requirements and develops both size and resource estimates. In addition, a defect estimate (the number of defects projected for the work) is made. All metrics are recorded on worksheets or templates. Finally, development tasks are identified and a project schedule is created. High-level design. External specifications for each component to be constructed are developed and a  component design is created. Prototypes are built when uncertainty exists. All issues are recorded and tracked. High-level design review. Formal verification methods are applied to uncover errors in the design. Metrics are maintained for important tasks and work results. Development. The component-level design is refined and reviewed. Code is generated, reviewed, compiled, and tested. Metrics are maintained for important tasks and work results. Postmortem. Using the measures and metrics collected (this is a substantial amount of data that should be analyzed statistically), the effectiveness of the process is determined. Measures and metrics should provide guidance for modifying the process to improve its effectiveness. ○ Team Software Process Watts Humphrey extended the lessons learned from the introduction of PSP and proposed a Team Software Process (TSP) The goal of TSP is to build a “self-directed” project team that organizes itself to produce high-quality software. Humphrey [Hum98] defines the following objectives for TSP: Build self-directed teams that plan and track their work, establish goals, and own their processes and plans. These can be pure software teams or integrated product teams (IPTs) of 3 to about 20 engineers. Show managers how to coach and motivate their teams and how to help them sustain peak performance. Accelerate software process improvement by making CMM 18 level 5 behavior normal and expected. Provide improvement guidance to high-maturity organizations. Facilitate university teaching of industrial-grade team skills. ○ Process Technology Process technology tools have been developed to help software organizations analyze their current process, organize work tasks, control and monitor progress, and manage technical quality. Process technology tools allow a software organization to build an automated model of the process framework, task sets, and umbrella activities. What is Agility? Agile software engineering combines a philosophy and a set of development guidelines. The philosophy encourages customer satisfaction and early incremental delivery of software; small, highly motivated project teams; informal methods; minimal software engineering work products; and overall development simplicity. Who does it? ○ Software engineers and other project stakeholders (managers, customers, end users) work together on an agile team—a team that is self-organizing and in control of its ○ own destiny. An agile team fosters communication and collaboration among all who serve on it. Why is it important? ○ The modern business environment that spawns computer-based systems and software products is fast-paced and ever-changing. Agile software engineering represents a reasonable alternative to conventional software engineering for certain classes of software and certain types of software projects. What are the steps? ○ Agile development might best be termed “software engineering lite.” The basic framework activities— communication, planning, modeling, construction, and deployment—remain. What is the work product? ○ Both the customer and the software engineer have the same view—the only really important work product is an operational “software increment” that is delivered to the customer on the appropriate commitment date. How do I ensure that I’ve done it right? ○ If the agile team agrees that the process works, and the team produces deliverable software increments that satisfy the customer, you’vedone it right. Agile Agile software process is characterized in a manner that addresses a number of key assumptions [Fow02] about the majority of software projects: 1. It is difficult to predict in advance which software requirements will persist and which will change. It is equally difficult to predict how customer priorities will change as the project proceeds. 2. For many types of software, design and construction are interleaved. That is, both activities should be performed in tandem so that design models re  proven as they are created. It is difficult to predict how much design is necessary before construction is used to prove the design. 3. Analysis, design, construction, and testing are not as predictable (from a planning point of view) as we might like. Agility Principles The Agile Alliance defines 12 agility principles for those who want to achieve agility: ○ Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. ○ Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. ○ Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. ○ Business people and developers must work together daily throughout the project. ○ Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. ○ The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. ○ Working software is the primary measure of progress ○ Agile processes promote sustainable development. The sponsors developers, and users should be able to maintain a constant pace indefinitely. ○ Continuous attention to technical excellence and good design enhances agility. ○ Simplicity—the art of maximizing the amount of work not done—is essential. ○ The best architectures, requirements, and designs emerge from self-organizing teams. ○ At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Extreme Programming the most widely used approach to agile software development. refines XP and targets the agile process specifically for use within large organizations. The XP Process ○ Planning The planning activity (also called the planning game) begins with listening—a requirements-gathering activity that enables the technical members of the XP team to understand the business context for the software and to get a broad feel for the required output and major features and functionality. ○ Design  XP design rigorously follows the KIS (keep it simple) principle. A simple design is always preferred over a more complex representation. In addition, the design provides implementation guidance for a story as it is written—nothing less, nothing more. ○ Coding After stories are developed and preliminary design work is done, the team does not move to code but rather develops a series of unit tests that will exercise each of the stories that is to be included in the current release (software increment). ○ Testing. The unit tests that are created should be implemented using a framework that enables them to be automated (hence, they can be executed easily and repeatedly). This encourages a regression testing strategy (Chapter 22) whenever code is modified (which is often, given the XP refactoring philosophy). Industrial XP ○ It is an organic evolution of XP ○ IXP differs most from the original XP in its greater inclusion of management, its expanded role for customers, and its upgraded technical practices.” ○ IXP incorporates six new practices Readiness assessment. The IXP team ascertains whether all members of the project community (e.g., stakeholders, developers, management) are on board, have the proper environment established, and understand the skill levels involved. Project community. The IXP team determines whether the right people, with the right 9skills and training, have been staged for the project. The “community” encompasses technologists and other stakeholders. Project chartering. The IXP team assesses the project itself to determine whether an appropriate business justification for the project exists and whether the project will further the overall goals and objectives of the organization. Test-driven management. An IXP team establishes a series of measurable “destinations” [Ker05] that assess progress to date and then define mechanisms for determining whether or not these destinations have been reached. Retrospectives. An IXP team conducts a specialized technical review (Chapter 20) after a software increment is delivered. Called  a retrospective, the review examines “issues, events, and lessons-learned” across a software increment and/or the entire software release Continuous learning. The IXP team is encouraged (and possibly, incented) to learn new methods and techniques that can lead to a higher-quality product. Other Agile Process Models Scrum ○ Is an agile software development method that was conceived by Jeff Sutherland and his development team in the early 1990s. DSDM ○ Dynamic Systems Development Method ( DSDM ) [Sta97] is an agile software development approach that “provides a framework for building and maintaining systems which meet tight time constraints through the use of incremental prototyping in a controlled project environment” [CCS02] Agile Modeling (AM) ○ It is a practice-based methodology for effective modeling and documentation of software-based systems. ○ Simply put, Agile Modeling (AM) is a collection of values, principles, and practices for modeling software that can be applied to a software development project in an effective and lightweight manner. ○ Agile models are more effective than traditional models because they are just barely good, they don’t have to be perfect. ○ Model with a purpose, Use multiple models, and Travel light, Content is more important than representation. Agile Unified Process (AUP) ○ adopts a “serial in the large” and “iterative in the small” [Amb06] philosophy for building computer-based systems. By adopting the classic UP-phased activities—inception, elaboration, construction, and transition—AUP provides a serial overlay (i.e., a linear sequence of software engineering activities) that enables a team to visualize the overall process flow for a software project. ○ Each AUP iteration addresses the following activities Modeling. UML representations of the business and problem domains are created. However, to stay agile, these models should be “just barely good enough” [Amb06] to allow the team to proceed. Implementation. Models are translated into source code. Testing. Like XP, the team designs and executes a series of tests to uncover errors and ensure that the source code meets its requirements.  Deployment. Like the generic process activity, deployment in this context focuses on the delivery of a software increment and the acquisition of feedback from end-users. Environment management. Environmental management coordinates a process infrastructure that includes standards, tools, and other support technology available to the team. Toolset for the Agile Process Collaborative and communication “tools” are generally low-tech and incorporate any mechanism (“physical proximity, whiteboards, poster sheets, index cards, and sticky notes” [Coc04] or modern social networking techniques) that provides information and coordination among agile developers. Active communication is achieved via team dynamics (e.g., pair programming), while passive communication is achieved by “information radiators” (e.g., a flat panel display that presents the overall status of different components of an increment). Project management tools deemphasize the Gantt chart and replace it with earned value charts or “graphs of tests created versus passed... other agile tools are using to optimize the environment in which the agile team works (e.g., more efficient meeting areas), improve the team culture by nurturing social interactions (e.g., collocated teams), physical devices (e.g., electronic whiteboards), andprocess enhancement (e.g., pair programming or time-boxing)”