2. Topics Covered in Presentation
Software Lifecycle – At a glance
Elements and Principles of Software
Software Development Activities
Challenges with Software Development
Problem solving Approach
Model driven development strategy
Risk vs Opportunity assessment
Software Development Lifecycle
Phases in development
Problems with the approach
Global and Legal Challenges
Opportunities in working with specific
6. Elements of Software
Software Requirements: target systems,
Architectural Design: target systems
Detailed Software Design: language, structure,
Implementation: languages, quality, version
Deployment and Acceptance Testing
Maintenance: regression testing, quality control,
bug tracking, version control
7. Principles of System
Get the system users involved.
Use a problem-solving approach.
Establish phases and activities.
Document through development.
Manage the process and projects
Justify systems as capital investments.
Don’t be afraid to cancel or revise scope.
Divide and conquer.
Design systems for growth and change.
8. Possible Identification of Software Development
What is the problem?
What is the solution?
What are the mechanisms
that best implement the
How is the solution
Is the problem solved?
Can the customer use the solution?
Are enhancements needed?
10. Inherent Challenges with Software
Requirements are complex
The client usually does not know all the functional requirements in advance
Requirements may be changing
Technology enablers introduce new possibilities to deal with nonfunctional
Frequent changes are difficult to manage
Identifying milestones and cost estimation is difficult
There is more than one software system
New system must often be backward compatible with existing system
Phased development: Need to distinguish between the system under
development and already released systems
11. Manage the Process and Projects
Process management –
an ongoing activity that documents, manages,
oversees the use of, and improves an organization’s
chosen methodology (the ―process‖) for system
development. Process management is concerned
with phases, activities, deliverables, and quality
standards should be consistently applied to all
is the process of scoping, planning, staffing,
organizing, directing, and controlling a project to
develop an information system at a minimum cost,
within a specified time frame, and with acceptable
12. Don’t Be Afraid to Cancel
or Revise Scope
Creeping commitment –
a strategy in which feasibility and risks are continuously reevaluated
throughout a project. Project budgets and deadlines are adjusted
Risk management –
the process of identifying, evaluating, and controlling what might go
wrong in a project before it becomes a threat to the successful
completion of the project or implementation of the information
system. Risk management is drive by risk analysis or assessment.
13. Where Do Systems Development
Projects Come From?
◦ an undesirable situation that prevents the organization from fully
achieving its purpose, goals, and/or objectives.
◦ a chance to improve the organization even in the absence of an
◦ a new requirement that is imposed by management,
government, or some external influence.
14. Where Do Systems Development
Projects Come From?
◦ An information systems strategy plan
has examined the business as a whole to identify
those system development projects that will return
the greatest strategic (long-term) value to the
◦ A business process redesign
has thoroughly analyzed a series of business
processes to eliminate redundancy and
bureaucracy and to improve efficiency and value
added. Not it is time to redesign the supporting
information system for those redesigned business
15. Use a Problem-Solving Approach
Classical Problem-solving approach
1. Study and understand the problem, its context,
and its impact.
2. Define the requirements that must be meet by any
3. Identify candidate solutions that fulfill the
requirements, and select the ―best‖ solution.
4. Design and/or implement the chosen solution.
5. Observe and evaluate the solution’s impact, and
refine the solution accordingly.
16. The PIECES Problem-Solving
the need to improve performance
the need to improve information (and
the need to improve economics, control
costs, or increase profits
the need to improve control or security
the need to improve efficiency of people
the need to improve service to customers,
suppliers, partners, employees, etc.
17. Model-Driven Development Strategy
Model-driven development –
◦ a system development strategy that emphasizes the drawing of system models
to help visualize and analyze problems, define business requirements, and
design information systems.
◦ Process modeling – a process-centered technique popularized
by the structured analysis and design methodology that used
models of business process requirements to derive effective
software designs for a system.
◦ Data modeling – a data-centered technique used to model
business data requirements and design database systems that
fulfill those requirements.
◦ Object modeling – a technique that attempts to merge the data
and process concerns into singular constructs called objects.
Object models are diagrams that document a system in terms of
its objects and their interactions.
18. Logical vs. Physical Models
Logical model –
a pictorial representation that depicts what a
system is or does.
Physical model –
a technical pictorial representation that depicts
what a system is or does and how the system is
19. Model-Driven Development
Easier to analyze
often more stable and
Systems can be
correctly the first time
Models only as good
Reduces users' role
because pictures are
Can be Inflexible
22. The System Development Life Cycle
What are guidelines for system development?
Arrange tasks into phases (groups
Involve users (anyone for whom
system is being built)
Develop clearly defined standards (procedures
company expects employees to follow)
23. What is a systems analyst?
Responsible for designing and
developing information system
Liaison between users and IT
24. What is the project team?
Formed to work on project from beginning to end
Consists of users, systems analyst, and other IT professionals
Project leader—one member of the team who
manages and controls project budget and
25. The System Development Life
What are some reasons to create or modify an
To correct problem
in existing system
Outside group may
lead to change
26. What is the system proposal?
ds the most
how system will
Formal request for new or modified information
system Also called project request
28. What is the analysis phase?
Read and understand the problem
Interview client to be clear about the
Develop a software specification:
Clear statement of problem
Basis of legal agreement
Agreed between analyst and client
Write a program which calculates and
displays the average of a set of
– How many numbers in set?
– What is maximum number?
– Are numbers integers, or real?
– What output device(s) to be used?
36. What is the planning phase?
Begins when steering committee receives project request
body for the
Function of committee:
team for each
37. What are possible solutions?
Buy packaged software—prewritten
software available for purchase
Write own custom software—software
developed at user’s request
Outsource—have outside source
needs of many
for particular industry
38. Logical Design Phase
Logical design –
◦ the translation of business user requirements into a system
model that depicts only the business requirements and not
any possible technical design or implementation of those
requirements. Common synonyms include conceptual
design and essential design.
System model –
◦ a picture of a system that represents reality or a desired
reality. System models facilitate improved communication
between system users, system analysts, system designers,
and system builders.
Analysis paralysis –
◦ a satirical term coined to describe a common project
condition in which excessive system modeling dramatically
slows progress toward implementation of the intended
39. Physical Design & Integration
Physical design –
◦ the translation of business user requirements into a system
model that depicts a technical implementation of the users’
business requirements. Common synonyms include technical
design or implementation model.
Two extreme philosophies of physical design
Design by specification –
◦ physical system models and detailed specification are
produced as a series of written (or computer-generated)
blueprints for construction.
Design by prototyping –
◦ Incomplete but functioning applications or subsystems (called
prototypes) are constructed and refined based on feedback
from users and other designers.
40. Construction and Testing Phase
Construct and test system components
User and System Interfaces
41. Installation and Delivery Phase
Deliver the system into operation
Deliver User training
Deliver completed documentation
Convert existing data
42. What is the support phase?
for users of a
system, as well as
required to deal
with any errors,
omissions, or new
system review—meeting to find
out if information system is
performing according to
Monitor system performance
44. Challenges in the Development
Difficulty of accommodating change
One phase has to be complete before moving onto the next phase
Inflexible partitioning of the project into distinct stages makes it difficult to respond
to changing customer requirements.
Only appropriate when the requirements are well-understood and changes will be
fairly limited during the design process.
Few business systems have stable requirements.
Mostly used for large systems engineering projects where a system is developed
at several sites.
Not targeting all goals of Model-Driven Engineering
Using model transformations which are not fully executable
Not testing the model
46. Legal challenges
Intellectual property rights—general
◦ Application and tools
Can you reuse your component?
Can you use it in a competitor’s application?
◦ Proprietary confidential information
Library source code, proprietary tools, data, …
◦ Test suites and case studies
Performance of partner applications or process
◦ Overlapping alliances and conflicts
47. Legal Challenges
Intellectual property rights
◦ Right to publish and disseminate
Revealing experimental results
◦ Indirect intellectual property
Insights developed in
Process and practices
Whose law governs what?
Leads to increased quality
leads to meaningful validation
results in software being less sensitive to changes in personnel
empowers domain experts
lets advanced programmers focus on the hard stuff
bridges the gap between business and IT
in software being less sensitive to changes in business
results in software being less sensitive to changes in technology
really enforces architecture
captures domain knowledge
provides up-to-date documentation
enables to focus on business problems instead of technology
provides you the ability to see your system at various levels
49. Our Learning's..
Development and maintenance processes our
Establish good software development practices
Capture/rescue important legacy software
Improve the quality of our software base:
portability (over many platforms and architectures)
design and structure
improve software quality
Where possible use tools to automate, to make
the process easier and more measurable
Ensure our developers adopt some good
practices and develop their own process of
50. What do we learn?
Much of Best Practice is common sense – however
is it formalised common sense
The essence of Best Practice is in definition and
Software development should be managed like any
The Best Practice outlined is a framework in which
The process steps have not been defined – these
are the remit of the project to defined, implement
There are some tools that can aid a process step
There is no magic bullet – software and
development process improvement is a long term