Software Engineering ch1

Fill in the blank with one of the four roles we identified in a software engineering process. 1. The client funds the project for the _________. 2. The SME has the interests of the _______. 3. The SME describes the problem to the _______. 4. The developers explain their solutions to the _______. 5. The developers deliver a system to the _______.

1. Developers 2. Client 3. Developers 4. SME 5. Users

Describe the four problems with the informal 'code and fix' approach to software systems development.

1. Developers start the project with no precise understanding of what the customer needs from the system and what the system is to deliver. No clear understanding of the features to be delivered. 2. No clear agreement between the developers and customer about when the project is finished. Without a precise definition, the customer can add and change the features to be delivered. Equally important, the development team is unable to estimate the time and budget needed to complete the project. 3. Without a precise definition at the start of the project, an adversary relationship between the customer and development team can form. The customer becomes frustrated with problems in delivered system versions and the developers frustrated with the constant changes demanded by the customer. 4. The constant thrashing and code revisions can lead to poorly structured code that is hard to understand and maintain.

Describe the importance of detecting defective or missing system requirements early in the project lifecycle.

A defect in the requirements that is identified early in the lifecycle can be fixed more easily (cheaply). This is because early in the lifecycle the only artifacts are documents and models. However later in the lifecycle, code will be written which represents a serious investment of developer resources. Finally, once the system has been delivered / put in production, any failures may damage the customer's ability to maintain their organization's revenue generating operations.

What sets Umbrella Activities apart from the activities executed during each of the six generic SDLC phases?

An Umbrella Activity is executed throughout the entire project i.e. across all phases of the generic SDLC.

Briefly describe two activities that take place during Post-Delivery Maintenance as described in the text.

Answer 1. Identification and repair of defects (bugs) in the delivered system. 2. Extension of the system with new features or enhancing existing features.

Applying 'Engineering Discipline' to software engineering implies problem solving by a repeatable process that involves what four activities?

Answer 1. Understanding the problem. 2. Designing and planning a solution to the problem. 3. Executing the solution in a predictable / scheduled lifecycle e.g. writing an application over a predicted period of time. 4. Ensuring that the solution is useful and safe.

Provide at least four reasons from the text describing why it is important that a project's documentation be maintained throughout the project lifecycle.

Any four of these five reasons... 1. Each lifecycle phase relies and builds on the knowledge built by its previous phase. For example, the system will be impossible to design without the knowledge of its requirements and domain analysis. Capturing (documenting) the results of each of the project's phases helps to ensure that the following phases will be correctly / completely executed. 2. It is common for project team members to leave the project throughout the project lifecycle. Current documentation protects the project from losing vital information concerning the project's purpose, goals, requirements, design decisions, etc. with the loss of an individual. 3. It is common for new team members to join the project throughout the project's lifecycle. Correct and up to date documentation provides a means of quickly educating new members joining the project as to the project's purpose, goals, requirements, design, etc. 4. Integration testing of the system must be complete. That is, all aspects of the system's operation must be covered by integration tests that validate the system's implementation. Detailed requirements and the other documents produced by the team give Quality Assurance the information they need to produce complete and correct integration test scenarios. Maintenance includes both fixing problems discovered after the system is in production and adding new features or modifying existing features. Because these activities are often carried out after development ends, it is often the case that developers other than those that originally constructed the system will be assigned the task of fixing or extending the system. Proper documentation will help to ensure that these changes can be made most efficiently and with less change of damaging the existing system.

What do Features and Requirements share in common? What is the difference between Features and Requirements?

Both features and requirements provide a means of capturing (recording) the services that a system is to deliver (implement). The difference lies in the how formally the services are described. A feature is a general, broad statement that informally describes a system's service e.g. Customer Management, Inventory Management, Order Processing, are all features of an ecommerce application. Each feature may be described in a few paragraphs to give the reader a general impression of the feature's purpose. Requirements are formal and detailed descriptions of the system's features. A requirement will describe in detail how a feature is to look or behave for the user. For example, one or more requirements will describe how a Customer is to be represented in the system i.e. its attributes, etc. Several requirements may be required to explain how Orders are to be created and tracked through the system. Features lack the detail expected in requirements. Features are often used to categorize the requirements that address the feature i.e. the many requirements describing in detail the feature Customer Management.

Describe the characteristics of "Programming in the Small" vs "Programming in the Large" as described in the text.

Programming in the Small describes a software project that is being executed by a single or few developers over a period of weeks or few months. The system is relatively simple and there are few requirements. Programming in the small requires little discipline and does not require following a software engineering process. Programming in the Large describes a software project that is being executed by many developers (>5) over a period of several months. The system is complex so there are many requirements whose implementation will involve building a large amount of code. This type of project requires the discipline of a software engineering process.

List and briefly describe what is accomplished by the development team during each of the six generic lifecycle phases described in the slides.

Requirements: Builds documents that list in varying levels of detail, the system's responsibilities i.e. what it needs to know and do. Analysis: Builds an in-depth understanding of the system's problem domain. Design: Builds models of the system's software structure. The design includes the classes and components to be build implementing the system. Implementation: Builds (code), integrate, and test the system's implementation. Includes both software and hardware components. Integration Testing: Tests the system as a functional whole. Testing performed after implementation, but before the system is delivered or put into production. Delivery: The delivery of the system to the customer or installing the software in the production environment making it available to its users.