Practical Considerations for Software Development

Rapport Technique , 2011 , 20 Pages

Informatique - Software

This book provides a practical approach to developing software. It introduces a framework concerned with the planning, analysis, design, and implementation of software. The framework is concerned with the entire software development process starting from identifying the business need for software and ending with the finished deliverables.

Table of Contents

Overview

Software Strategy
Planning
Analysis and Design
Implementation

Appendix I: Key Terms

Table of Figures

Figure 1: Example Activity Diagram

Figure 2: Use Case Description Example

Figure 3: Use Case Diagram Example

Figure 4: CRC Card Example

Figure 5: Example Class Diagram (without relationship mappings)

Overview

This book provides a practical approach to developing software. It introduces a framework concerned with the planning, analysis, design, and implementation of software. The framework is concerned with the entire software development process starting from identifying the business need for software and ending with the finished deliverables.

Software Strategy

The goal is to deliver quality software to the client. The software project is planned, analyzed, and design to create a “blueprint” before coding is started. These are essential steps taken before the programmer starts implementation (coding) to ensure the programmer has specific requirements, obtainable goals, and a measurable workload.

Each phase has deliverable(s):

- Planning: Program specifications (requirements document)
- Analysis and Design: Class diagram (converts to skeleton code)
- Implementation: Program release

Planning

This section states the essential steps in the planning phase: the concept of the software (the business need), feasibility analysis and creating requirements. Planning starts with conceptualizing the idea and ends with requirements. The planning stage goal is a requirements document (program specification) to give to the programmer (or possibly software systems analyst).

Involvement level:

- Team members with high involvement: managers, stakeholders
- Team members with some involvement: developer

Planning starts with the software concept: either a team member or a stakeholder in the organization conceives an idea to fulfill a business need. This idea is generally a business solution for a problem. For example

- Business need: Organization XYZ wants to cut paper consumption
- Business solution: Create a software system that stores documents electronically to reduce paper consumption

Once the concept of a business solution is created, management must decide the feasibility of the project. This may consist of deciding if it is worth investing in the development of a software solution and whether it can be done. If the project is approved, the requirements document or program specification is created.

The program specification document is a requirements document that states the features and goals of the software. The document should contain an overview, key terms, scope, skeleton/demo (optional), milestones (goals), code review (testing plan), and project management information. The sections are as follows:

- Overview: the purpose of the program and the business need it solves
- Key terms: common words, technical terms, acronyms, etc. pertaining to the program specification document
- Scope: a very high level outline of the program features and specifications
- Skeleton/Demo (optional): screenshots or drawn forms of the user interface
- Milestones: The program goals. Use the scope section and select a several goals which will be obtained be either a version number or date

NOTE: It is possible for the Concept à Feasibility Analysis à Requirements steps to go through several iterations. For example, if the software concept is created, management may want a draft of program specifications too see if the project is feasible. MS Visio can be used to draw demo .NET forms to show a concept or a small skeleton program may be created to show the functionality.

Analysis and Design

This section describes the analysis and design phase of software development which integrates UML 2.0 to create a “blueprint” of the software system. The “blueprint” will be used by the programmer in the implementation phase to code the software. Each UML diagram and document is discussed in each subsection. The program specifications should contain enough information to start analysis and design. Five essential UML diagrams and documents are created in this process: activity diagram, use case descriptions, use case diagram, CRC cards, and class diagram. UML diagrams are drawn with CASE tools or general diagram drawing software (MS Visio). UML documents are templates created from a word processor.

The UML documents and diagrams are created by either a programmer or analyst familiar with UML. These created documents/diagrams are meant to help the technical staff develop the software. It is recommended the diagrams are reviewed by peers, but review under the discretion there is never a perfect diagram. Each diagram and document is a general explanation of each entity. The goal is diagrams have a logical flow and the documents have general detail.

Involvement level:

- Team members with high involvement: programmer or software systems analyst
- Team member with some involvement: managers, stakeholders

Activity Diagram

When the planning phase is complete, a program specification document is created and given to the software systems analyst or programmer. The goal of this diagram is to draw a high level flow of each process in the program. It also states the basic logic of the program in a step-by-step series. UML’s activity diagram is a flow chart, but it includes tools to conceptualize ideas for object-oriented analysis and design. The program specifications are used to generate the activity diagram. The steps to draw an activity diagram are as follows:

1. Read the overview and scope sections of the program specifications document
2. Each item in scope should translate into one or more activities
3. Draw the activity on the diagram

Draw this diagram with certain discretion: the emphasis is high level: if the activity is “process item,” do not break down the activity into “store in array” or “use malloc().” The diagram generally states the method/function/subroutine calls that are in the main routine.

Figure 1: Example Activity Diagram

illustration not visible in this excerpt

• Université: University of Fairfax
• Cours: Software Development
• Auteur: Eric Vanderburg (Auteur)
• Année de publication: 2011
• Pages: 20
• N° de catalogue: V205029
• ISBN (ebook): 9783656348696
• ISBN (Livre): 9783656348795
• Langue: anglais
• mots-clé: practical, considerations, software, development