SEN2022

SOFTWARE ENGINEERING ANALYSIS AND DESIGN

➢ chapter 1

Why do Software Projects Fail?

1. Unclear or vague project requirements

• Ensure that the end product meets the actual expectations of the customer.
• Ask a lot of questions to the customer until you clarify intentions for the project.
2. Poor or limited communication
• improve communication within the team to ensure developers are on the same page.
• Improve communication with the customers.
3. Poor planning
• One person should control project execution.
• Speak facts and numbers to the client and be as transparent as possible.
• If a deadline is unrealistic, make sure that the client is aware of it.
4. Substandard engineers
5. Lack of leadership
6. Poor communication
7. Inadequate use of resources
8. Inability to overcome challenge.

Tips to make your software projects succeed.

1. Define the project’s goals.

2. Establish a project team structure.
3. Set realistic deadlines.
4. Communicate effectively with stakeholders.
5. Analyze the project’s challenges and opportunities.
 Systems / Software Development Life Cycle (SDLC)

• The process of understanding how an information system (IS) can support business needs by
designing a system, building it, and delivering it to users.
• SDLC is a process used by a systems analyst to develop an information system, including
requirements, validation, training, and user (stakeholder) ownership.
• The System Analyst is the key person:
• Designs a system to add value.
• Must understand the business processes.
• Job is rewarding yet challenging.
• Requires specific skill sets.

a) Planning phase

• Understanding “why” an IS should be built, what value will it provide and time it’ll take to build it
1. Project Initiation
i. Technical feasibility (can we build it?)
ii. Economic feasibility (will it provide business value?)
iii. Organizational Feasibility (if we build it, will it be used?)
2. Project Management
i. Work plan is created, staff the project and monitor it.

b) Analysis phase

• Who will use the system? What will the system do? When will it be used?
1. Analysis Strategy
i. Study of the current system (called the “as-is system”), its problems, and ways to design a new
system (“to-be system”)
2. Requirements Gathering
i. develop a system concept.
ii. System concept then used as a basis to develop a set of business models that describe how
the business will operate if the new system were developed.
3. System Proposal
i. Presenting the system concept and models to the project sponsor and other key decision
makers who will decide whether the project should continue to move forward
c) Design phase

• How should we build it? how will operate in terms of the hardware, software, and network
infrastructure that will be in place?

1. Develop design Strategy.

i. Clarifies whether the system will be developed by the company’s own programmers,
outsourced to another firm, or whether the company will buy an existing software package

2. Develop architecture and interfaces

i. What hardware, software, and network infrastructure will be used.
ii. Interface Design- how will users move through the system?

3. Develop database and file Specifications

i. Defines exactly what data will be stored and where they will be stored.

4. Develop the program Design

i. Defines the programs that need to be written and exactly what each program will do.

d) Implementation phase

System is built (or purchased)

1. Construction
2. Installation
3. Support

Which Methodology to Use?

 SDLC: Methodologies / Process Models

➢ Classes of methodologies

1. Structured Development

i. Waterfall Development
• The analysts and users proceed in sequence from one phase to the next
• The key deliverables for each phase (documentation) are presented to the project sponsor for
approval
• Once the sponsor approves the work, the phase ends and the next one begins
• Two sets of diagrams are used: Process-model diagramsData-model diagrams.
• Advantages:
• The system requirements are identified long before programming begins.
• Changes to the requirements as the project proceeds are minimized
• Disadvantages:
• The design must be completely specified before programming begins
• A long time elapses between the completion of the system proposal in the analysis phase and the
delivery of the system
• What if the project team misses important requirements? Expensive post-implementation programming
• What if the business environment changes after the analysis phase? (addressed by parallel dev)

ii. Parallel Development

• Addresses, What if the business environment changes after the analysis phase?
• Attempts to avoid long delays between the analysis phase and the delivery of the system
• First a general design for the whole system is created
• Then, the project is divided into a series of distinct subprojects that can be designed and
implemented in parallel
• Finally, the separate pieces are integrated and the system is delivered
• Advantages
• it reduces the time to deliver a system (less changes)
• Disadvantages
• Sometimes the subprojects are not completely independent.
2. Rapid Application Development

• Aim: reduce the time the system meets its users the first time
i. Phased development-based methodology

• The overall system is broken into a series of

versions that are developed sequentially.
• Analysis phase identifies the overall system
concept.
• The overall system requirements are
classified.
• Advantages:
• The system quickly gets into the hands of
the users.
• The users can identify important additional
requirements sooner than with structured
design methodologies.
• The system begins to provide business value
although being incomplete.
• Disadvantages
• The users begin to work with incomplete
systems.
• It is critical to identify the most important and useful features and include them in Version 1
• User’s expectations should be managed!

ii. Prototyping-based methodology

• Analysis, design, and implementation phases performed concurrently.
• A system prototype is generated (quick program with minimal features)
• The first prototype is shown to the users (and the project sponsor) for their comments
• Another prototype is generated.
• Repeated and refined till its accepted.
• Advantages
• The users can interact with the (incomplete) system very quickly.
• The users see the gradual progress.
• Real requirements are refined very quickly.
• Disadvantages
Fast-paced system releases can harm complete methodological analysis.
• For complex systems, fundamental issues and problems may not be recognized until well into the
development process.
iii. Throwaway Prototyping-based methodology

• A thorough analysis phase is used to develop the system concept

• A design prototype is analyzed, designed, and implemented.
• Not a working system
• A product that addresses the issues related to specific features.
• Aims to help users understand the issues under consideration.
• Several prototypes are developed until all the issues are resolved
• These prototypes are used to ensure that important issues are understood before the real system is
built
• Then, the design prototypes are thrown away.
• Then the project moves into design and implementation.
• Advantages:
• Balance the benefits of well-thought-out analysis and design phases with the advantages of using
prototypes to refine key issues before the system is built.
• Throwaway prototyping methodology usually produces more stable and reliable systems. (than
prototyping-based)
• Disadvantages:
• Throwaway prototyping can take longer (than prototyping-based) to deliver the final system.

3. Agile Development
• focus on the system development.
• Aim to eliminate much of the modeling and documentation overhead and the time spent on those
tasks.
• All agile development methodologies are based on the agile manifesto and a set of twelve principles
• Virtually all agile methodologies are used in conjunction with object-oriented technologies.
• All agile development methodologies follow a simple cycle through the traditional phases of SDLC
• Criticisms:
• Requires co-location of the development team.
• Development is not carefully managed.
• No actual documentation created during the development.
• Can they deliver large mission-critical systems?
i. Extreme Programming (XP)
• Founded on four core values: communication, simplicity, feedback, and courage
• Developers must
• Provide rapid feedback to the end users on a continuous basis
• Follow the KISS principle
• Make incremental changes to grow the system, and they must not only accept change, they must
embrace change
• Have a quality-first mentality
• Key principles:
• Continuous testing
• Code is tested each day and is placed into an integrative testing environment.
• Simple coding performed by pairs of developers
• Close interactions with end users to build systems very quickly
• XP is recommended only for small groups of developers (<10)
• XP is not advised for large mission-critical applications
• XP needs a lot of on-site user input, many business units cannot commit

ii. SCRUM

• A term from rugby: a scrum is used to restart a game.

• The creators believe that no matter how much you plan, as soon as the software begins to be
developed, chaos breaks out and the plans go out the window.
• Teams are self-organized and self-directed
• A typical Scrum team size is no more than seven members.
• Once a sprint has begun, no additional requirements are considered
• New requirements are placed on a backlog of requirements that still need to be addressed.
• At the beginning of every workday, a Scrum meeting takes place.
• At the end of each sprint, the team demonstrates the software to the client.
• A sprint lasts thirty working days
• Based on the results of the sprint, a new plan is begun for the next sprint.