ee. > @¢ e ee e@eeeeoeveoeoenoeoaeaeeeoenaseseeeesee © @eeoeoeeeeveveneeneeoene eee © @ @ ee? Information Systems & Software Engineering Information Systems & Software EngineeringInformation Systems & Software Engineering Software and Software Engineering CHAPTER OVERVIEW AND COMMENTS The goal of this chapter is to introduce software and software enginecring, Software isa “Product” designed and built by software enginoors. Software is important because tt has an impact of vinually every aspect of our lives. Software engineers have a moral and ethical responsibility to ensure thatthe software they build does no serious harm and meets the needs of the people who request it and those who use it. Software engineers tend to be concerned with the technical elegance oftheir software products. Customers tend to be concemed only with whether or not a software product meets their needs and is easy to use Software is designed and built by software engincers. Software is used by virtually everyone in society, Software is pervasive in our commerce, our culture, and our everyday lives Software engineers have a moral obligation to build reliable sofware that does no harm other people. Software engineers view computer software, as being made up ofthe programs, documents, and data required to design and build the system Software users are only concemed with whether or not softw: fare products meet their expectations and make their tasks easier to complete. MPORTANT QUESTIONS FOR SOFTWARE ENGINEERS Why does it take so long t0 get software finished? Can it be done fister? Why are development costs so high? Can it be made more efficiently (less expensive)? ‘Why can't we find all errors before we give the software to our customers? Why do we spend so much time and effort maintaining existing programs? Why do we continue to have difficulty in measuring progress as software is being developed? SOFTWARE Software is both a product and a vehicle for delivering a product information) Software is engineered, not manufactured Software does not wear out, but it does deteriorate. Industry is moving toward component-based software constriction, but most software is stil custom-built 0% 05 05000 0 0® 0p Op Cy 0) 0000000000 C0 6 6D 6999609 O OOO OO OO OiInformation Systems & Software Engineering SOFTWARE APPLICATION ‘System software Application software Engineering or Scientific Software Embedded software Product-line sofiware (includes entertajnment so ftware) Web-Applications Artificial intelligence software NEW SOFTWARE CHALLENGES COpen-world computing - Creating software to allow machines of all sizes to communicate with each other across vast networks Netsourcing - Architecting simple and sophisticated applications that benefit targeted end-user markets worldwide Open Source - Distributing source code for computing applications so customers can make local modifications easily and reliably FOR LEG: TEM Evi Software must be adapted to meet needs of new computing environments or technology Software must be enhanced to implement new business requirements Software must be extended to make it interoperable with more modern system components Software must be re-architected to make it viable within a network environment SOFTWARE ENGINEERING REALITIES Problem should be understood before software solution is developed Design is a pivotal activity Software should exhibit high quality Software should be maintainable SOFTWARE ENGINEERING Software engineering is the establishment of sound engineering principles in order to obtain reliable and efficient software in an economical manner. LC . aSInformation Systems & Software Engineering iz Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, Software engi the use of tools. jeering encompasses a process, management techniques, technical methods, and GENERIC SOFTWARE PROCESS FRAMEWORK Communication (customer collaboration and requirement gathering) Planning (establishes engineering work plan, describes technical risks, lists resources required, work products produced, and defines work schedule) Modeling (creation of models to help developers and customers understand the requires and software design) Construction (code generation and testing) : Deployment (software delivered for customer evaluation and feedback) WARE ENGINEERING UMBRELLA ACTIVITIES Software project tracking and control (allows team to assess progress and take corrective action to maintain schedule) Risk management (assess risks that may affect project outcomes or quality) Software quality assurance (activities required to mai fain software quality) Technical reviews (assess engineering work products to uncover and remove errors before they propagate to next activity) * Measurement (define and collect process, project, and product measures’ to assist team in delivering software meeting customer needs) Software configuration management (manage effects of change) Reusability management (defines criteria for work product reuse and establish mechanisms to achieve component reuse) ‘Work product preparation and production (activities to create models, documents, logs, forms, lists, etc.) TTRIBI OM R MODELS Overall flow and level of interdependencies among tasks Degree to which work tasks are defined within each framework activity Degree to which work products are identified and required Manner in which quality assurance activities are applied —_—_—_—_—_—_—_—_———_—_ AG SSS 9 8 8 Sifstal o,0,e, oe e, »% %Information Systems & Software Engineering Manner in which project tracking and control activities are applied Overall degree of detail and rigor of process description Degree to which stakeholders are involved in the project Level of autonomy given to project team Degree to which team organization and roles are prescribed ESSENCE OF PRACTICE Understand the problem (communication and analysis) Plan a solution (software design) Camry out the plan (code generation) Examine the result for accuracy (testing and quality assurance) NDERSTAND THE PROBLEM Who are the stakeholders? What functions and features are required to solve the problem? Is it possible to create smaller problems that are easier to understand? Cana graphic analysis model be created? PLAN THE SOLUTION Have you seen similar problems before? Has a similar problem been solved? Can readily solvable sub-problems be Wlefined? Cana design model be created? CaRRY OUT THE PLAN Does solution conform to the plan? Is each solution component provably correct? EXAMINE THE RESULT Is it possible to test each component part of the solution? conform to the data, functions, and features required? Does the solution produce results thiInformation Systems & Software Engineering ‘I SSS ‘SOFTWARE PRACTICE CORE PRINCIPLES Software exists to provide value to its users Keep it simple stupid (KISS) Clear vision is essential to the success of any software project Always specify, design, and implement knowing that someone else will have to understand what ‘you have done to carry out his or her tasks Be open to future changes, don’t code yourself into a corner Planning ahead for reuse: reduces the cost and increases the value of both the reusable ‘components and the systems that require them Placing clear complete thought before any action almost always produces better results SOFTWARE CREATION Almost every software project is precipitated by a business need (e.g. correct a system defect, adapt system to changing environment, extend existing system, create new system) Many times an engineering effort will only succeed if the software created for the project succeeds. The market will only accept a product is the software embedded within it meets the customer's stated or unstated needs. eo e © ° @ é é é e © e oe © e e e e é é é e e é e ° °eeoe ee eeaeeeenvuneendoeaoeceen eee 6 @ eeeeoeveaeeeeoeeese eee @ Information Systems & Software Engineering Process: A GENERIC VIEW CuapTer OverViEW AND COMMENTS ‘This intent of this chapter is 9 establish a definition for software engineering and to present a generic software process model that can be used as a template for all other process models presented in Chapter 3. A process framework, encompassing five activities — communication, planning, modeling, construction, and deployment—is presented. SOFTWARE ENGINEERING - A LAYERED TECHNOLOGY Software engineering encompasses a process, the management of activities, technical methods, and use of tools to develop software products. Fritz, Bauer defined Software engineering as the “establishment and use of sound engineering principles in order fo obtain economically software that is reliable and works efficiently on real ‘machines. * IEEE definition of software engineering (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). We need discipline but we also need adaptability and agility. Software Engineering is a layered technology as shown below. Any engineering approach must rest on an organizational commitment to quality. tools E 2 ~ methods a» ae process model _ a “quality” focus a9 ly,Information Systems & Software Engineering The bedrock that supports software engineering is a quality focus. The foundation for S/W eng is the process layer. It is the glue that holds the technology layers together and enables rational and timely development of computer S/W. Process defines framework that must be established for effective delivery of S/W eng technology. The software process forms the basis for management control of software projects and establishes the context in which technical methods are applied, work products (models, documents, data, reports, etc.) are produced, milestones are established, quality is ensured, and change is properly managed. SAW eng, methods provide the technical “how to’s” for building S/W. Methods encompass a broad array of tasks that include communication, req. analysis, design, coding, testing and support. ‘SMW eng tools provide automated-or semi-automated support for the process and the methods. When tools are integrated so that info. Created by one tool can be used by another, a system for the support of S/W development called computer-aided software enigineering is established. A PROCESS FRAMEWORK Software process models can be prescriptive or agile, complex or simple, all-encompassing or targeted, but in every case, five key activities must occur. The framework activities are applicable to all projects and all application domains, and they are a template for every process model, +Software process Process framework Umbrella activities Framework activity #1 Software Engineering action Each framework activity is populated by a set of S/W eng actions ~ a collection of related tasks that produces a major S/W eng work product (design is a S/W eng action). Each action is Populated with individual work tasks that accomplish some part of the work implied by the action \ The following generic process framework is applicable to the vast majority of S/W projects ‘Communication: involves heavy communication with the customer (and other stakeholders) and encompasses requirements gathering, Planning: Describes the technical tasks to be conducted, the risks that are likely, resources that will be required, the work products to be produced and a work schedule ‘A10 BM Oy 00% 000% %MHSHHHSHNS 8599999389998 338 FInformation Systems & Software Engineering Modeling: encompasses the creation of models that allow the developer and customer to better ‘understand S/W req. and the design that will achieve those req. Construction: combines'code generation and the testing required uncovering errors in the code. Deployment: deliver the product w the customer who evaluates the delivered product and provides feedback \ ction is represented by a number of different task sets ~ each a collection of S/W related work products, quality assurance points, and project milestones, Each S/W en eng work tas ‘The task set that best accommodates the needs of the project and the characteristics of the team is chosen, ‘The framework described in the generic view of S/W eng is complemented by a number of umbrella activities. Typical activities include: SIW project tracking and control: allows the team to assess progress against the project plan and take necessary action to maintain schedule. Risk Management: Assesses the risks that may affect the outcome of the project or the quality, Software quality assurance: defines and conducts the activities required to ensure software quality. Formal Technical Review: uncover and remove errors before they propagate to the next action. ‘Measurement: defines and collects process, project, and product measures that assist the team in delivering S/W that meets customers’ needs. Software configuration management: Manages the effect of change throughout the S/W process Reusability management: defines criteria for work product reuse. Work product preparation and production: encompasses the activities required to create work products such as models, documents, etc ‘THE CAPABILITY MATURITY MODEL INTEGRATION(CMMI ‘The Software Engineering Institute (SEI) has developed a comprehensive process meta-model that is predicated on a set of system and software eng eapabilities that should be present as organizations reach different levels of process capability and maturity. ‘The CMMI defines each process area in terms of “specific goals” and the “specific practices” required to achieve these goals. implied by a process Specific goals establish the characteristics that must exist if the activities area are to be effective. Specific practices refine a goal into a set of process-related activities. Zi 5 All_—_ The software process can be defined as a collection of pattems that defines a set of activities, actions, work tasks, work products required to develop computer S/W. The use of software patterns is becoming increasingly popular as organizations try to reduce costs by reusing both process and product artifacts in new projects. Ex: nage 34 PROCESS ASSESSMENT The process should be assessed to ensure that it meets a set of basic process criteria that have been shown to be essential for a successful software engineering. This is used by industry professionals. 1 The Personal Software Process (PSP) model is good from the perspective that an individual software engineer can use it to improve his or her personal productivity and work product quality PSP process mode! defines five framework activities: planning, high-level design, high-level design review, development, and postmortem. It stresses the need to identify errors early and to understand the types of errors, Planning: it isolates reqs. And a project schedule is created High-level design: Prototypes are built when uncertainty exists High-level design review: Formal verification methods are applied 10° uncover errors in the design. : Development: Code is generated, reviewed, compiled, and tested. Postmortem: using the measures and metrics collected, the effectiveness of the process is determined, ‘TEAM SOFTWARE Process (TSP The goal of TSP is to build a “self-directed” project team that organizes itself to produce high- quality sw Each project is “launched” using a “script” that defines the tasks to be accomplished, Teams are self-directed, Measurement is encouraged Measures are analyzed with the intent of improving the team process. —ee——$_$ — Az % @ eo e © © e e dl © © oe & © eo o e& © e e é é e é é @ é e ° é.@ee@e@eeeoeeeoenaeeeoeee_/d eese@eoeateoaeeoe eee Information Systems & Software Engineering PROCESS TECHNOLOGY Acquire a process technology tool and demonstrate its capabilities. Emphasize that the key to success is a process that is tuned to the people, the project and the product. Tools help. But they are not a panagea,PRESCRIPTIVE PROCESS MODELS CHAPTER OVERVIEW AND COMMENTS This intent of this chapter is to present process model to manage large-scale software projects. However, every project needs to conform software development activities that can organize the work products that need to Is used by professional software developers No software process works well for every project, a {© some systematic process in order to manage casily get out of control. Sofware processes help to be produced during a software development project, Ultimately the best indicator of how well a software process has worked is the quality of the deliverables produced. A well-managed process will produce high quality products on time and within budget PRESCRIPTIVE MODELS Many people (and not a few professors) believe that prescriptive models are “old school"— Ponderous, bureaucratic document-prodhicing machines, THE LL MODEL Planning esating Seneauting tracking delivery suppor teedoack Many people dismiss the waterfall as obsolete and it cemainly does have problems. But this ‘model can still be used in some situations Among the problems that are sometimes encountered when the warerfill model is applied 2re: A Real project rarely follows the sequenti confusion as the project proceeds. flow that the model proposes. Change can cause Wis difficult for the customer to state all the requirements explicitly. ‘The waterfall model requires such demand. The customer must have patience. A wi the project time-span, INCREMENTAL PROCESS MONELS The process models in this cate indusiry AM ‘orking of the program will not be available until late in ‘gory tend to be among the most widely used (and effective) in the Deployment] Im % HOO COCCOHO ©29200000609280838229800 @3e e . Ce Information Systems & Software Engineering ce What are the drawbacks of the RAD model? ry : For large, but scalable projects, RAD requires sufficient human resources to ereate the right ce number of RAD teams, If developers and customers are not committed to the rapid-fire activities necessary to complete the system in a much abbreviated time fame, RAD project Ce will fal, Ifa system cannot properly be modularized, building the components necessary for RAD will be problematic. ee Team #n e ~ Meeelng Co ons ec uote coe senraten veg Communicatiog Modeling busines modeling °e Gata noting cess modeling e proce @ e = Construction Deployment ®e snr Integraion autonaticense us e neta i. . - cs Modeling tela i feedback | =: business modeling &6 data modeling e process modeling e e ° ‘ e Construction é e component reuse| @ automatic code e generation e e testing e e @ e °e e e° : STTTiacale e® sic ln dl iformation Systems & Software Engineering ‘THEINCREMENTAL MODEL The incremental model combines elements of the waterfall model applied in an iterative fashion. ‘The model applies linear sequences int a staggered fashion as calendar time progresses. Each linear sequence produces deliverable “increments” of the software, (Ex: a Word Processor delivers basic file mgmt., editing, in the first increment; more sophisticated editing, document production capabilities in the 2" increment; spelling and grammar checking in the 3“! increment. When an increment model is used, the 1% increment is often a core product. ‘The core product is used by the customer, As a result of use and / or evaluation, a plan is developed for the next increment. The plan addresses the modification of the core product to better meet the needs of ! the customer and the delivery of additional features and functionality. The process is repeated following the delivery of each increment, until the complete product is produced. If the customer demands delivery by a date that is impossible to meet, suggest delivering one or more increments by that date and the rest of the Software later. 2 5 vexed z ch 5 ChE} ee = ° es g serement # 2 - aniecenent | 5 . .: | g "or 3 Sp ashen Poe a | a iS ‘o a project calendar time THe L Rapid Application Development (RAD) is an incremental software process model. that emphasizes a short development cycle. RAD is a “high-speed” adaptation of the waterfall model, | in which rapid development is achieved by using a component based construction approach. If requirements are well understood and project scope is constrained, thé RAD process enables a ! development team to create a fully functional system within a short period of time. SESSSLSSSSSSSESSSSISSISISSSSIPSSIIS SF Sideett ceeeewsoneebee eee eeestsas Geeovecvesecasccvevsecrvcosces Information Systems & Software Engineering EVOLUTIONARY PROCESS MODELS Software evolves over a period of time; business and product requirements often change as development proceeds, making a straight-line path to an end produet unrealistic sommodate a Software Engineering needs a process hodel that has been explicitly designed to a product that evolves over time. Evolutionary process models arc iterative. They produce increasingly more complete versions of the Software with each iteration, Prororye Customers often define a set of general objectives for Software, but doesn’t identify detailed input, processing, or input requirements. Prototyping paradigm assists the Software engineering and the customer to better understand ‘what isto be built when requirements are fuzzy. Deployment Delivery & Feedback Construction of prototype_———eeeeeeeeeeee The prototyping paradigm begins with communication where requirements and goals of Software are defined. Prototyping iteration is planned quickly and modeling in the form of quick design occurs. ‘The quick design focuses on a representation of those aspects of the Software that will be visible to the customer‘“Human interface” ‘The quick design leads to the: Construction of the Prototype. ‘The prototype is deployed and then everluated by the customer. Feedback is used to refine requirements for the Software. Iteration occurs as the prototype is tuned to satisfy the needs Of the customer, while enabling the developer to better understand what needs to be done. The prototype can serve as the “first system". Both customers and developers like the prototyping paradigm as users get_a feel for the actual system, and developers get to build Sofware immediately. Yet, prototyping can be problematic: The customer sees what appears 1 be a working version of the Software, unaware that the prototype is held together “with chewing gum. “Quality, long-term maintainability.” When informed that the product is a prototype, the customer cries foul and demands that few fixes be applied to make it a working product. Too often, Software development management relents. ‘The developer makes implementation compromises in order to get a prototype working quickly. An inappropriate O/S or programmirig language used simply bie it's available and known. After a time, the developer may become comfortable with these choices and forget all the reasons why they were inappropriate . The Key is to define the rules of the game at the beginning. The customer and the developer ‘must both agree that the prototype is built to serve as a mechanism for defining requirements, SPUR, EL The spiral model is an evolutionary Software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model. thas two distinguishing features A cyclic approach for incrementally growing a system's degree of de: while decreasing its degree of risk ition and implementation A set of anchor point milestones for ensuring stakeholder commitment to feasible and mutually satisfactory solutions. Using the spiral model, Software is developed in a series of evolutionary releases. —ee—e —— AB %%HHD9F9F99S FHI PHF IES GS IPPIPPIPI IEF KoMo%o% |@oaeoeneeeee e@eoeeoseoeveve @ e t Information Systems & Software Engineering During early stages, the release might be a paper model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced. {A spiral model is divided into a set of framework activities divided by the Software engineering team. {As this evolutionary process begins, the Software team performs activities that are implied by a circuit around the spiral in a clockwise direction, beginning at the center. Risk is considered as each revolution is made. “Anchor-point milestones ~ a combination of work products and conditions that are attained along. the path of the spiral- are noted for each evolutionary pass. ‘The first circuit around the spiral might result in the development of a product specification; subsequent passes around the spiral might be used to develop a prototype and then progressively more sophisticated versions of the Software. Each pass through the planning region results in adjustments to the project plan. Cost and schedule are adjusted based on feedback derived from the customer after delivery. Unlike other process models that end when Software is delivered, the spiral model can be adapted to apply throughout the life of the Software. planning estimation scheduling Fisk analysis, communication modeling analysis design deployme: Lalita construction delivery ost feedback iett ‘THE CONCURRENT DEVELOPMENT MODEL The concurrent development model, sometimes called concurrent engineering, can be represented schematically as a series of framework activities, Sofiware engineering actions of tasks, and their associated states, ANDInformation Systems & Software Engineering The concurrent model is often more appropriate for system engineering projects where different engineering teams are involved. Moseling activity represents tnetats Under aineering development BPP Po Merk PF o% 00's é Figure above provides a schematic representation of one Software modeling activity for the concurrent process niodel. of the states noted at any given time. ngineering task within the ‘The activity ~ modeling- may be in any one Alll activities exist concurrently but reside in different states. 3 For example, early in the project the commumication activity has completed its first iteration and exists in the awaiting changes state, ‘The modeling activity which existed in the none state while initial communication was completed now makes a transition into underdevelopment state, If, however, the customer indicates the changes in requirements must be made, the modeling activity moves from the under development state into the awaiting changes state ‘The concurrent process model defjnes a series of events that will trigger transitions from state to State for each of the Software engineering activities, actions, or tasks, ‘A20 STSELIUSLSSESELLSFPES?Peoeeeneoeoeaee eee eee 0 @ eeeuaxoeenceceovoesceseoeeoeeoue Sot ‘ale Information Systems & Software Engineering ‘SPECIALIZED PROCESS MODELS PONENT. VELOPM Commercial off-the-shelf (COTS) Software components, developed by vendors who offer them as products, can be used when Software is to be built. These components provide targeted functionality with well-defined interfaces that enable the component to be integrated into the Software. ‘The component-based development model incorporates many of the characteristics of the spiral model. ‘The component-based development model incorporates the following steps: ‘Available component-based produe's are researched and evaluated for the application domain in question. Component integration issues are considered. Software architecture is designed to accommodate the components. ‘Components are integrated into the architecture. Comprehensive testing is conducted to ensure proper fiznetionality. ‘The component-based development model leads to Sofiware reuse, and reusability provides Software engineers with a number of measurable ben ‘THe FORMAL MeTHops Mopé! ‘The Formal Methods Model encompasses a set of activities that leads to formal mathematical specifications of Software. Formal: methods enable a Software engineer to specify, develop, and verify a computer-based system by applying a rigorous, mathematical notation. A. variation of this approach, called clean-room Software engineering is currently applied by some software development organizations. ‘Although not a mainstream approach, the formal methods model offers the promise of defect- free Software. Yet, concem about its applicability in a business environment has been voiced: The development of formial models is currently quite time-consuming and expensive, B/C few software developers have the necessary background to apply formal methods, extensive training is required. It is difficult to use the methods as a communication mechanism for technically unsophisticated customers.Jnformation Systems & SoRware Engineering ASPECT-ORIENTED SOFTWARE DEVELOPMENT Regardless of the software process that is chosen, the builders of complex software invariably implement a set of localized features, functions, and information content. For further information read book page 61 THE UNIFIED PRocEss(UP) A “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML). The UP is an attempt to draw on the best features and characteristics of conventional software Process models, but characterize them in a way that implements many of the best principles of agile software development. The UP recognizes the importance of customer communication and streamlined methods for describing the customer’s view of a system. It emphasizes the important role of software architecture and “helps the architect focus on the right goals, such as understandabitity, reliance to future changes, and reuse.” UML provides the necessary technology to support Object Oriented Software Engineering Practice, but it doesn’t provide the process framework to guide project teams in their application of the technology. The UML developers developed the Unified Process, a framework Object Oriented Software Engineering-using UML. PHASES OF THE UNiFIED Process ‘The figure below depicts the phases of the UP and relates them to the generic activities The Inception phase of the UP encompasses both customer communication and plann activities. By collaborating with the customer and end-users, 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 A22 POLE SISCCLVUESESssssss see?e @Oor&’-eeceCoeooaovoeeeeoe e @ ee2eeeeneneoene oe eed e @ Information Systems & Software Engineering Elaboration Inception construction = transition aN, production ‘A use-case describes a sequence of actions that are performed by an actor (person, machine, ‘another system) as the actor interacts with the Software. ‘The elaboration phase encompasses the customer communication and modeling activities of the generic process model. 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 sofiware - the use-case model, the analysis model, the design model, the implementation model, and the deployment model. of the UP is identical to the construction activity defined for the generic ‘The consiruetion phas software process. input, the construction phase develops or acquires the software ‘case operational for end-users. Using the architectural model components that will make each use~ ‘The wunsition phase of the UP encompasses the latter stages of the generic construction activity and the first part of the generic deployment activity. Software is given to end-users for beta testing, and user feedback reports both defects and necessary changes. 'At the conclusion of the transition phase. the software inerement becomes a usable software release (user manuals, trouble-shooting guides, and installation procedures). ‘The production phase of the UP coincides with the development activity of the generic process “The on-going use ofthe software is monitored, support forthe operating environment is provided and defect reports and requests for changes are submitted and evaluated — —_—$ ‘Az3Information Systems & Software Engineering A Software Engineering workflow is distributed across all UP phases. UP Phases Inception Elaboration | Construction | Transition Production Workflows Requirements Analysis Design Implementation Test ‘Support erations Au 05000999999 A1ADDDDDA DADA AR HH oO to!Information Systems & Software Engineering 7 AGILE DEVELOPMENT OVERVIEW AND COMMENTS WHAT Is AGILITY? ‘The main point of this section is to introduce agility in the context of software development. Agility is more than change management. Agility means that customers and developers need to work together as collaborators on the development team and try to build products that can be adapted to a rapidly changing market place. Part of this adaptation is learning when and how to streamline the production of work products and focus on the development of incremental operational prototypes. ‘A manifesto is normally associated with an emerging political movement-one that attacks the old guard and suggests revolutionary change. “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools. Working software over comprehensive documentation Customer collaboration aver contract negotiation Responding to change over following a plan ‘That is, while there is value in thelitems on the right, we value the items on the left more.” Agility is today's buzzword when describing a modern software process. It is how to appropriately respond to changes. Change is what software development is very much about, Changes in the software being built, changes to team, members, changes because of new technology that may have impact on the project that creates the product. ‘Agility encompasses the philosophy espoused in the manifesto noted earlier. It adopts the customer as a part of the development team and works to eliminate the “us and them” attitude that continue to pervade many software projects. 7 AzSnee ey PRINCIPLES BEHIND THE AGILE MANIFESTO We follow these principles: 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 hamess 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 A26 929,29 @° 3 HM H%HHHSHNHHNDDHO9000 0900we wodeea ratotd oe ieee cee eee eee é OP Information Systems & Software Engineering WHAT IS AN AGILE PROCESS? Any agile soffware process is characterized in a manner that addresses three key assumptions; It is difficult to predict in advance which software requirements will persist and which will change and which customer priorities will change. Design and construction are interleaved, Both activities should be performed in tandem so that design models are proven as they are created ‘Analysis, design, construction, and testing are not as predictable as we might like. ‘An agile software process must adapt incrementally. ‘To adapt incremental adaptation, an agile team requires customer feedback. ‘An operational prototype is ai effective catalyst for customer feedback. Hence, incremental development strategy should be instituted. Software increments (executable prototypes) must be delivered in short time so that adaptation keeps pace with change. AGILE PROCESS MODELS Is driven by customer descriptions of what is required (scenarios) Recognizes that plans are short-lived Develops software iteratively with a heavy, ‘emphasis on construction activities Delivers multiple ‘software increments? Adapts as changes occur It encompasses a set of planning, design, The most widely used agile process, originally proposed by Kent Beck. rules and practices that occur within the context of four framework aetiviti coding and testing,Information Systems & Software spike solutions simple design | GRC cards prototypes user stories values acceptance test criteria ieration plan Programming Release software increment unit test Brojact valocty computed continuous integration acceptance testing PLANNING Begins with the creation of “user stories” and then placed on an index card. The customer assigns a value to the story based on the overall business value of the function, Agile “XP” team assesses each story and assigns a cost “measured in development weeks,” If stories take more than 3 weeks to develop, the customer is asked to split the stories into smaller ones. Stories are grouped to form a deliverable increment “done by customer and XP team.” Once a commitment is made on delivery date, the XP team orders the stories that will be developed in one of three'ways. All stories will be implemented immediately within a few weeks. The stories with the highest value will be moved up in the schedule and implemented first ‘The riskiest stories will be moved up in the schedule and implemented first After the first increment (project release), “project velocity” is used to help define subsequent delivery dates for other inerements Project velocity is the number of customer stories implemented during the first release t Project velocity can be used then to: Help estimate delivery dates and schedule for subsequent releases, and A28 082382008 relate ete % % % % % 1% %%$S$$SS9HO9 8 e: ee ,@OCCCHCHCEOHSECESSESCHHELEHOLOE SE eo02e800082000 © Bae ee ese © yy E Information Systems & Software Engineering : Determine whether an over-commitment has been made for all stories across the entire development project. DESIGN XP Follows the KIS(S) principle. representation. simple design is always preferred over a more complex Encourage the use of CRC (class-responsibility collaboration) cards which identity the O-O classes that are relevant to the current software increment. nd organize For difficult design problems, suggests the creation of “spike solutions” — a design prototype that is implemented and evaluated. Encourages “refactoring” — an iterative refinement of the intemal program design that controls the code modifications by suggesting small design changes that may improve the design. 4 IN Recommends the construction of a unit test for a story before coding commences Encourages “pair programming” where two programmers work together at one workstation to create code for a story. “Two heads better than one.” ‘TESTING ‘All unit tests are executed daily which provides the XP team with a continual indicaion of progress and also can raise warning flags early if things are going awry. “Acceptance tests” are defined by the customer “user stories” and executed to assess customer visible functionality ‘Apaprive Sorrw, VEL Was originally proposed by Jim Highsmith. ASD: A technique that is used for building complex sofiware and systems. Highsmith defines ASD lifecycle that incorporates 3 phases: speculation, collaboration, and learning. Speculation: An adaptive cycle-planning is conducted where it uses the customer's: mission statement, project constraints (delivery dates, user description) and basic requirements. ~ ‘429 iisInformation Systems & Software Engineering Collaboration: eople working together must trust one another to: * Criticize without animosity Assist without resentment + Work as hard or harder as they do © Have the skill set to contribute to the work at hand * Communicate problems or concerns in a way that leads to effective action LEARNING Learning will help them to improve their level of real understanding, adaptive cycle planning Requirements gathering uses mission statement YAD Project constraint s mini-specs basic requirement s time-boxed release plan ‘ Release software increment adjustments for subsequent cycles components implement ed/ tested focus groups for feedback formal technical reviews Post mort ems. Dywaic System DEVELOPMENT METHOD (DSDM Promoted by the DSDM Consortium Dynamic Sysiem Development Method is an agile S/W 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. a A30 ® . % e@ SCeeoeeegeeone00 2ae020e0e200800800e8 PFC RC CHOCOESC OLE CeO Information Systems & Software Engineering It defines three different iterative cycles preceded by two additional life cycles activities Feasibility Study: Business requirements aiid constraints. Business Study: Establishes requisitions that will allow the application to provide business value. Functional Model Iteration: Produce iterative prototypes. Design and build iteration: Revisit prototyping, Implementation: Include the latest prototype into the operational environment. SCRUM Originally proposed by Schwaber and Beedle; the name derived from an activity that occurs during a mgby match. Scrum — distinguishing features Development work is partitioned into “packets” Testing and documentation are on-going as the product is constructed Work occurs in “sprints > framework activities” and is derived from a “backlog > requirements that provide business values” of existing requirements Meetings are very short and sometimes conducted without chairs “Demos” are delivered to the customer with the time-box allocated e AgSS PRACTICE: A GENERIC VIEW Al OMMI ‘This intent of this chapter is to present the concepts and principles that serve as a foundation for software engineering practice. The concepts and principles presented in this chapter are applicable regardless of the specific process that is used, methods that are chosen or tools that are applied. Note: In many cases, the concepts and principles discussed here should be revisited as each software engineering activity is presented during the course, For example, design concepts and principles can be revisited when the chapters on software design are covered, SOFTWARE ENGINEERIN' PRACTICE Practice is a broad array of concepts, principles, methods, and tools that you must consider as software is planned and developed. It represents the details — the technical considerations and how to's — that are below the surface of the software process — the things that you'll need to actually build high-quality computer software. THE ESSENCE OF PRACTICE This section lists the generic framework (communication, planning, modeling, construction, and Geployment) and umbrella (racking. risk management, reviews, measurement, configuration ‘management, reusability management, work product creation, and product) activities found in all software process models George Polya, in a book written in. 1943 (!), describes the essence of software en practice ... \eering Understand the problem (communication and analysis). Who are the stakeholders? ‘What are the unknowns? “Data, functions, features to solve the problem? Can the problem be compartmentalized? “Smaller that may be easier to understand? Can the problem be represented graphically? Can an analysis model be created? Plan a solution (modeling and software design), Have you seen a similar problem before? Mas a similar problem been solved? If so, is the solution reusable? Can sub-problems be defined ‘A32 wih wlele a's 6 0 peta SO bh Sseseevsvseoscc cctbidacaaaeeeen ee cueeaees f7ee t Information Systems & Software Engineering amanner that leads to effective implementation? Can you represent a solution Carry out the plan (code generation). Does the solution conform to the plan? Is each component part of the solution probably correct Examine the result for accuracy (testing and quality assurance), Is it possible to test each component part of the solution? Does the solution produce results that conform to the data, functions, features, and behavior that are required? PRINCIPLES ‘The Reason It All Exists; Provide value to the customer and the user. If you can’t provide value, then don't do it KISS—Keep It Simple, Stupid! All design should be as simple as possible, but no simpler. “This facilitates having a more easily understood and easily maintained system, intial to the succes Maintain the product and project “vision.” 4 clear vision is ¢ ofa sw project. What you produce, others will consume. Alvays specify, design, and implement knowing ‘someone else have to understand what you are doing, Be open to the Future, Never design yourself into a corner. Always ask “what if,” and prepare ‘yourself for all possible answers by creating systems that solve the general problem, not just the specific one. Plan Ahead for Reuse. Planning ahead for reuse reduces the cost and increases the value of both the reusable components and the systems into which they are incorporated. ‘Think! Placing clear, complete thought before action almost always produces better results, COMMUNICATION PRACTICES Before customer requirements can be analyzed, modeled, or specified they must be gathered through a communication (also called requirement elicitation) activity. Effective communication (among technical peers, with the customer and other stakeholders, and with project managers) is among the most challenging activities that confront a S/W engineer. In this contest, the following are communication principles and concepts that apply to customer ‘communication: Listen: focus on the speaker's words, rather than formulating your response 10 those words. Be a polite listener. illInformation Systems & Software Engineering Prepare before you communicate: Spend the time to understand the problem before you meet with others “research” Someone should facilitate the communication activity. Have a leader “moderator” to keep the conversation moving in a productive direction. Face-to-face communication is best. Take notes and document decisions Collaborate with the customer. Each small collaboration serves to build trust among team members and creates a common goal for the team. Stay focused, modularize your dise ion. The facilitator should keep the conversation modular; leaving one topic only after has been resolved. Draw pictures when things are unclear. Conse yon agree to something, move on; (b) if you can't agree to samething, mave ones (¢) x «feature or function is unclear and can't be clarified at the moment, more on Negotiation is not a contest or a game, It works best when both parties win, PLANNING PRACTICES sry uanning activity encompasses a set of management and technical practices that enable the S/W team to define a road map as it travels toward its strategic goal and tactical objectives, Regardless ofthe rigor with which planning is condueted, the following principles always apply: Understand the project scope. Scope provides the S/W team with a destination, Involve the customer (and other stakeholders) in the planning activity, The customer defines Briorties and establishes project constraints, S/W engineers must often negotiate order of delivery, timelines, and other related issues. Recognize that planning is iterative. A plan must be adjusted to accommodate changes, Estimate based on what you know. The intent of estimation isto provide an indication of effort, Gost and task duration, based on the team's current understanding of the work to be done Consider risk as you define the plan Be realistic. Even the best S/W engineers make mistakes Adjust granularity as you plan. A fine granularity plan provides significant work task detail that is planned over relatively short time increments. A coarse granularity plan provides broader work tasks that are planned over longer time periods Define how quality will be achieved. Pefine how youl accommodate changes. “Can the custonier request a change at any time? y Track what you've planned and make adji A34 lave! 2 o% 8 PP LP 9@ 9 On Open 00)eeocecooce © © © © © © 0 © 0060 0 ogee ahe ole? © OH ww w~ eeeeroroeeeosooee? Information Systems & Software Engineering Bary Boehm states: “Yn need an organizing principle that scales down to provide simple plans for simple projects.” i nd schedules, Bochm. suggests an approach that addresses project objectives, milestones, responsibilities, management and technical approaches, and required resources Boehm calls it WSHH principle, after a series of questions that lead toa definition of Key project characteristics and the resultant project plan. Why is the system being developed? Does the business purpose justly the expenditure of people, time and money? ‘What will be done? Identify the functionality to be built. When will it be accomplished? Establish a workflow and timeline for key project tasks and identify milestones required by the customer. Who is responsible for a function? Define members’ roles and responsibilities. Where are they located (organizationally)? Customers also have responsibilities. How will the job be done technically and managerially? Once a scope is defined, a technical strategy must be defined. : How much of each resource is needed? ‘The answer is derived by developing estimates based ‘on answers to earlier questions. MODELING PRACTICES ‘The process of developing analysis and design models is described inthis section. The emphasis je ow describing how to gather the information needed to build reasonable mpdels, but no specific modeling notations are presented in this chapter. UML. and) other modeling notations are described in detail later in the text In S/W Eng. work, two models are created: analysis models and design models: “Analysis models represent the customer requirements by depicting the SW if these different Soa ne he infomation domain, the functional domain, and the behavioral domain. Design models represent characteristics of the S/W that help practitioners to construct it effectively: the architecture, the user interface, and component-level detail ANALYSIS MODELING PRINCIPLES ‘The information domain of a problem must be represented and understood. The ‘information domain encompasses the data that flow into the system (end-users, other systems, or extemal devices), the data that flow out of the system and the data stores that collect and organize persistent data objects. A35formation Systems & Software Engineering Represent software functions. Functions can be described at many different levels of abstraction, ranging from a general statement of purpose to & detailed description of the processing elements that must be invoked. Represent software behavior. The behavior of the S/W is driven by the interaction with the extemal environment. ‘The models that depict information, function, and behavior must be partitioned in a manner that ‘uncovers detail in a layered fashion (or hierarchical), ‘The analysis task should move from essential information toward implementation detail. Analysis begins by describing the problem from the end-user perspective. The”essence” of the problem is described without any consideration of how a solution will be implemented. ‘DESIGN MODELING PRINCIPLES ‘The software design model is the equivalent of an architect's plans for a house, Set of principles used: Design must be traceable to the analysis model. The analysis model describes the information domain of the problem, user visible functions, system behavior, and a set of analysis classes that package business objects with the methods, that service them. The design model translates this information into architecture: a set of subsystems that implement major functions, and a set of component-level designs that are the realization of analysis class. Always consider architecture. S/W architecture is the skeleton of the system to be built. Only after the architecture is built should the component-level issues should be considered, Focus 6n the design of data as it is as important as a design, Data design is an essential element of t architectural design. Interfaces (both user and internal) must be designed. A well designed interface makes integration casier and assists the tester in validating component functions. User interface design should be tuned to the needs of the end-user. “Ease of use.” Component-level design should exhibit functional independence. The functionality thet is delivered by a component should be cohesive- that is, it should focus on one and only one function. Components should be loosely coupled to one another and to the external environment. Coupling is achieved in many ways — via a component interface, by messaging through global data. Coupling should be Kept as low as is reasonable. As the. level of coupling increases, error propagation also increases and the overall maintainability of the system decreases A36 ®@éee SOM OTOOOSSSSSESESIS ORI OS OPP OBB 2.8 @@@eeee @eee@ “e e e “o e ® e . e @ °e °e @ @® @® eeseenvee & Inforsnation Systems & Software Engineering Design representation (models) should be easily understood. ‘The design model should be developed iteratively. With each iteration the designer should strive for greater simplicity. CONSTRUCTION PRACTICES In this text “construction” is defined as being composed of both coding and testing. The purpose of testing is to uncover defects. Exhaustive testing is not possible so processing a few test cases successfully does not guarantee that you have bug free program. Unit testing of components and integration testing will be discussed in greater later in the text along with software quality assurance activities Although testing has received increased attention over the past decade, itis the weakest part of software engineering practice for most organizations. DING PRINCIPLES AND CONCEPTS Preparation Prineiples: Before writing one line of code, be sure of: Understand the problem you are trying to solve Understand the basic design principles. Pick a programming language that meets the needs of the S/W to be built and the environment in which it will operate. i Select a programming environment that provides tool that will make your work easier. Create a set of unit tests that will be applied once the component you code is completed Coding Principles: As you begin writing code, be sure you Constrain your algorithm by following structured programming practice. Select the proper data structure. 2 Understand the software architecture. Keep conditional logic as simple as possible, Create easily tested nested loops. Write code that is self documenting, Create a visual layout Validation Principles: After you've completed your first coding pass, be sure you Conduct a code walkthrough. Perform unit test and correct errors. 437Information Systems & Software Engineering eee Refactor the code. ‘TESTING PRINCIPLES Testing is a process of executing a program with the intent of finding errors. A good test is one that has a high probability of finding an as-yet undiscovered error. A successfill test is one that uncovers an as-yet-undiscovered error. DEPLOYMENT PRACTICES Customer Expectations for the software must be managed. “Don't promise more than you can deliver.” A complete delivery package should be assembled and tested. A support regime must be established before the software is delivered, Appropriate instructional materials must be provided to end-users, Buggy software should be fixed first, delivered later. DSSSESSLEESPPPIPS PPD MMeeet ar o fe peseerteoved Information Systems & Software Engineering SYSTEM ENGINEERING OVERVIEW AND COMMENTS ‘This intent of this chapter is to provide a brief introduction to the system engineering process. ‘The overall structure of computer-based systems is discussed! and a brief overview of the system engineering hierarchy is presented. Business process engineering (BPR) and product engineering are discussed in overview fashion. ‘Note: Some reviewers of this edition argued that a discussion of system engineeritig.is beyond the scope of a software engineering text. S/W Engineering occurs as a consequence of a process called System engineering. System Engineering focuses on analyzing, designing, and organizing those elements into a system that can be a product, a service, or a technology for the transformation of information COMPUTER-BASED SYSTEMS This section introduces the systems view of engincering (all complex systems can be viewed as 'g composed of cooperating subsystems). ‘The elements of computer-based systems are defined as software, hardware, people, database, documentation, and procedures. ‘A computer-based system makes use of a variety of system elements. Software: programs, data structures, and related work products. Hardware: electronic devices that provide computing capabilities People: Users and operators of hardware and software. Database: A large, organized collection of information that is accessed via S/w and persists over time. Documentation: manuals, on-line help files. Procedures: the steps that define the specific use of each system element. One complicating characteristic of computer-based system is that the elements constituting one system may also represent one macro element of a still large system. The micro-clement is a computer-based system that is one part of a larger computer based system. YSTEM ENGINEERING HI “The key to system engineering isa clear understanding of context, For software development this means creating a "world view" and progressively narrowing its focus until all technical detail is known, A39nformation Systems & Software Engineering In software engineering there is rarely one right way of doing something. Instead designers must consider the tradeoffs present in the feasible solutions and select one that seems advantageous for the current problem. This section lists several factors that need to be examined by software engineers when evaluating alternative solutions (assumptions, simplifications, limitations, constraints, and preferences), Regardless of its domain of focus, system eng. Encompasses a collection of top-down and bottom-up methods to navigate the hierarchy illustrated below: The system eng. Process usually begins with a “world view.” The entire business or product domain is examined to ensure that the proper business or technology context can be established The world view is refined to focus more fully ona specific domain of interest. Business or Product Domain World view Domain of interest Domain view System element Element view beste enes eee eee aes Semele ewes] Lets eten eee oon sas aaa boeal nasa] Detailed view Within a specific domain, the need for targeted s analyzed, ‘stem elements (data, S/W, H/W, and people) is Finally, the analysis, design, and construction of a targeted system element are initiated. —_—_ ‘A40eo é é ¢ é é Information Systems & Saftware Engineering ‘SYSTEM MODELING \ System modeling is an important element of the system eng. Process. ‘The Engineer creates models that: Define the processes that serve the needs of the view under consideration. Represent the behavior ofthe processes and the assumptions on which the behavior is based. Explicitly define both exogenous and endogenous input to the model Exogenous inputs link one constituent of a given view with other constituents the same level ‘sfother levels; endogenous input links individual components of a constitivent at a particular view. Represent all linkages (including output) that will enable the engineer to better understand the view. To construct a system model, the engineers should consider a number of restraining factors: “Read examples of each in book page# 127.” “Assumptions that reduce the number of possible permutations and variations, thus enabling @ ‘model reflect the problem in a reasonable manner. ‘Simplifications that enable the model to be created in a timely manner. Limitations that help to bound the system. Constraints that will guide the manner in which the model is‘ereated and the approach taken ‘when the model is implemented. Preferences th indicate the preferred architecture forall data, Functions, and technology. BUSINESS P| VERVIE! The goal of Business Process Engineering (BPE) is to define architectures that will enable 2 business to use information effectively. BPE is one process for creating an overall plan for implementing the computing architecture. ‘Three different architectures must be analyzed and designed within the context of business objectives and goals: Data architecture Application architecture Technology infrastructure ‘The data urchitecure provides a framework for the information needs of a business. The building blocks ofthe architecture are the data objects that are used by the business ‘AaYInformation Systems & Software Engineering Onee a set of data objecis is defined, their relationships are identified. A re! ‘lationship indicates how objects are connected to one another. The application archicecure encompasses those elements of a system that transform objects within the data architecture for some business purpose, The technology infrastructure provides the foundation for the data and application architectures, The infrastructure encompasses the h/w and s/w that are used to support the applications and data. The comple — Engine cring: PRODUCT ENGINEERING: AN OVERVIEW Emphasize that sofware engincers participate in that begins with requirements engineering. The analysis step maps requirements into ipDresentations of data, function, and behavior. The design step maps the analysis model into data, architectural, interface, and sofiware component designs SYSTEM MODELING WITH UM In terms of the data that describe the eler Deployment diagrams all levels of the product engineering process ment and the operations that manipulate the data Each 3-D box depicts a hardware element that is part of the physical architecture of the system Activity diagrams Represent procedural aspects of a system element nena en Aaz 0% 0 ©, ©, ©, 0, ©, 0, 0.0.0, 0) & © © © e060 © ©Information Systems & Software Engineering Class diagrams Represent system level elements .sSprocessor read barcode get conveyor speed STP COMTroler lacquisition subs Conveyor Bor code reager Shunt actuator | _Plse toch get shunt status read varcode —) ( get conveyor status) 443 @eeeeeeaeeeneeeeenoeoeaeaeeeeeeeeee peSeoceeeceseoseeoeoeeeeeee eclass name Box barcode forwardSpeed height width depth weight contents ae | readBarcode() updat eSpeed () readSpeed() updat eLocation() readLocation() get Dimensions) get Weight() checkContents() conveyorLocation ——— | ae paul attributes note use of capital letter for muiti-word attribute names operations (parentheses at end of name indicate the lst of attributes that the ‘operation requires) Aaa aeccr #5969 000% % © 0 0 000 ® eee 0° 0% °0 800 "0" 00% % %F 2°o2 eee Pr @@ paceoceoorce Information Systems & Software Engineering REQUIREMENTS ENGINEERING OveRviEW AND COMMENTS The intent of this chapter is to present requirements enginvering tasks and basic requirements analysis concepts and principles. Regardless of the process mode! used by software engineers, requirements engineering is an essential part of a successful software development project. The focus of this chapter is'gathering the information needed to build the information, function, and behavioral portions ofthe atalysis model. ~ y Understanding the requirements of a problem is among the most difficult tasks that face a software engineer. THE BRIDGE TO DESIGN AND CONSTRUCTION In this section, requirements engineering is described as a bridge between communication and analysis modeling, design and construction, For all new systems, the requirements engineering process should start with a feasibility study. The input to the feasibility study is a set of preliminary business. requirements, an outline description of the system and how the system is intended to support business processes. ‘The results of the study should be a report that recommends whether or not itis worth carry on with the requirements engineering and system development process. Many software engineering’ developers want to jump right in before they have a clear understanding of what is needed. [A feasibility study isa short, focused study that aims to answer a number of questions: Does the system contribute to the overall objectives of the organization? Can the system be impleinented using current technology and within given cost and schedule constraints? Can the system be integrated with other systems which are already in place? “The hardest single part of a software engineering system is deciding what to bi No part of the work so cripples resulting system if done wrong. Not other part is more difficult to rectify later” Fred Brooks. Requirement Engineering is a software engineering action that begins during communication activity and continues into the modeling activity —_—_—_$_$—$—$<—_—$ ———_— ———————————————v—mxvrl————eeEeEeEeEeEeEeEeeeEeEeEeEeEeEeE———————————————————————————— “It is essential that the software engineering team attempts to make a real effort to understand the requirements of a problem before the team attempt to solve the problem. RE establishes a solid base for design and construction, Without it, the resulting software has a high probability of not meeting customers’ needs. REQUIRE! NGINEI TASKS RE provides the appropriate mechanism for understanding what the customer wants, analyzing need, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the specification, and managing the requirements as they are transformed into an operational system, INCEPTION How does a software engineering 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. At project inception, software engineers ask a set of questions that establish bas ic 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 customer and the developer Eviciation Christel arid. Kang identify a number of problems that help us understand why requirements elicitation is difficult: Problems of scope: The boundary of the system is ill-defined. Problems of understanding: The customers/users are not completely sure of what is needed, have poor understanding of the capabilities and limitations of their computing environment. don't have a full understanding of the problem domain, specify requirements that conflict with the needs of other customers/usets, or specify requirements that are ambiguous or unstable. Problems of volatility: The requirements change over time. A46 F345 45OO9 9939999999999 9009 Bwrrewmor:0°00 eo & 6 0°09 ee‘ eeese eeeo t Information Systems & Software Engineering ELABORATION Elaboration is an analysis modeling action that is composed of a number of mod refinement tasks. ing and Elaboration is driven by the creation and refinement of user scenarios that describe how the end- user will interact with the systems NEGOTIATION It is not unusual for customers and users to ask for more than can be achieved given limited business resources, ‘The requirements engineer must reconcile these conflicts through a process of negotiation Customers, users, and other stakeholders, are asked to rank requirements and then discuss conflicts in priority. E Risks associated with each requirement are identified and analyzed, hence, rough “guestimates” ‘of development efforts are made. SPECIFICATION ‘A specification can be any one (or more) of the following: A written document A set of models A formal mathematical ‘A collection of usage scenarios (use-cases) A prototype ‘The specification is the final work product produced by the requirements engineer. It serves as the foundation for subsequent software engineering activities. It describes the function and performance of a computer-based system and the constraints that will gover its development. LD, Requirements validation examines the specification to enslire that all software requirements have been sated unambiguously; that inconsistencies, omissions, and errors have been detected and corrected; and that the work products conform to the standards established for the process, the project and the produc. AATInformation Systems & Software Engineering ‘The primary requirements validation mechanism is the formal rechnical review. ‘The review team that validates requirements includes software engineers, customers, users, and other stakeholders who examine:the specification looking for errors in content or interpretation, areas where clarification may be required, missing information, inconsistencies, conflicting requirements, or unrealistic requirements. ‘REQUIREMENTS MANAGEMENT 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. ‘The process of initiating engineering is the subject of this section. The point of view described is having all stakeholders (including customers and developers) involved in the creation of the system requirements documents, The following are steps required to initiate requirements engineering: Ine! THI EH A stakeholder is anyone who benefits in a ditect or indirect way from the system which is being developed. [Sommerville and Sawyer] 1 In the book stakeholders are: operations managers, product managers, marketing people, intemal and extemal customers, end-users, consultants, product engineers, software engineers, support and maintenance engineers, etc. At inception, the requirements engincer should create a list of people who will contribute input as requirements are elicited. ‘The initial list will grow as stakeholders are contacted because every stakeholder will be asked “Who else do you think | should talk to?” ‘RECOGNIZING MULTIPLE ViEWPOINTS Each of the stockholders will contribute to the RE process. As information fom multiple viewpoints is collected, emerging requirements may be inconsistent or may conflict with one another. The requirements engineer is to categorize all stakeholder information ineluding inconsistencies and conflicting requirements in a way that will allow decision makers to choose an internally inconsistent set of requirements for the system. nnn e @ ° 8 8 ° ° ° ° @ é é é @ @ é é é a e %