Software Life Cycle Requirements and problem analysis. –What exactly is this system supposed to do? Design –How will the system solve the problem? Coding –Translating the design into the actual system.

Software Life Cycle Testing –Does the system solve the problem? –Have the requirements been satisfied? –Does the system work properly? Maintenance –Bug fixes

Requirements The initial step is to determine what the system must do. –The requirements document is developed to document the customer’s and user’s expectations of the software. Requires data and potentially interaction with the customer and actual users.

Requirements Once the team has an understanding of the requirements the next step is to determine how the system will behave. –The result of this step is the functional specification document. –The document contains: How the system operates The user interface look and feel The system input and outputs Error handling

Design Specification After the team understands how the system will behave, the next step is to determine how to implement the system. –The result of this step is the Design document.

Design Specification –The design document contains: The class organization. The classes and instance variables. The methods with specific return type and parameters Any complex algorithms

Implementation Once the design is “complete” the implementation begins.

Testing The testing phase should begin as soon as there are reasonable implementations to verify. –The first step is to develop test cases. –The second step is to run the test cases. –The third step is to report any problems back to the programmers. –We will talk more about testing in a few days.

From Specification to Design There are multiple approaches to developing the design. The following represent some good steps to take when developing a design. –Determine what your system objects are: Look for noun phrases that represent objects. Look for key components in the requirements and specification documents.

From Specification to Design –Determine what the possible methods are: Look for actions that identify behaviors. Look for verb phrases in the requirements and functional specification. –Identify the possible classes. Define classes that represent objects. Try to group nouns into classes if they represent a more general entity. Remove duplicate and extraneous nouns.

From Specification to Design –Write a statement that describes the purpose of each class that has been identified. What are the behaviors of this class and what will they do. –Define the class structure. Put logically connected state and behaviors into the same class. If a behavior requires an attribute of a class, put the behavior in the same class.

From Specification to Design –Define the communication and relationships between classes. Does a class require information from another class to perform the defined behaviors? Discard classes that do not interact with other classes. They most likely are not needed.

From Specification to Design –Refine the system design Review classes to see if they should be combined. Review collaborations between classes to see if they can be defined in a more streamlined manner. –Prepare a class diagram. Unified Modeling Language (UML)

Design Example Develop a system that will convert US dollars to Japanese Yen, French Francs, or Chinese Yuan. The user enters an amount and a currency for the conversion. The output should list the entered amount in US dollars followed by the converted amount with the currency name. If the user enters a currency that does not exist, a proper error message should be printed.