Вы находитесь на странице: 1из 41

SDLC

Software Engineering
Project Management Practices
System
All systems can be divided into : Natural Systems (Solar, Neurological, Virological) and Man-
made (Procedural, Physical, Conceptual)
• A PROCEDURAL system is a coordinated set of consistent principles, rules and procedures
to be followed to resolve some problem or perform some task e.g., gambling,
mathematical and logical systems.
• Man-made PHYSICAL systems are coordinated and connected assemblies, organized
collections of physical elements intended and designed to serve a common purpose e.g.,
the braking system of an automobile, the electrical or lighting system etc. Social systems
are organized and coordinated groups of people working together to serve mutual
interests or achieve a common purpose.
• A CONCEPTUAL system is a consistent theory or coordinated body of facts, principles and
hypothesis by which some aspect of reality may be ordered, explained or understood.
Organizations are organized system of men, machines, materials and energies or resources.
A study of these systems may be done by studying their structure, content, communication
and control.
What exactly is a System?
• A system is a composite entity made up of inter-related or inter-dependent
functional units
• Every system has a goal or objective
• A system works within a boundary
• A system acts under a common control which coordinates the activities of the
different functional units
• Any malfunction of any one system component affects the function of the entire
system
• A system is synergetic, which means the effect of the sum of the functional units
is greater than the sum of the effects of the individual functional units
• Every man-made system has got a lifetime
• System Concepts : Boundary and Environment, Subsystem, interface, Black box,
Feedback Control
System - Definitions
• A system is a composite entity made up of inter-related or inter-dependent
functional units which act in coordination under a common control for
achieving a common objective.
• A set of procedures that constitute activities that are logically grouped
together to form one unique function within an organization.
• A set of interacting elements responding to inputs to produce outputs.
• Business Systems : interaction with environment, purpose, self-regulation,
self-correction
• Systems Concept/Approach : A system is a set of components that interact
to accomplish some purpose
• Systems Analysis is the process of studying the network of interactions
within an organization and assisting in the development of new and
improved methods for performing necessary work
Characteristics of a System
The information provided by the system should be consistent, accurate, timely, economically feasible and relevant
• Establishes standards so you can write procedures on how to do the job
• Specifies each area’s responsibility to introduce accountability for managers for the work they manage
• Delineates actions and decisions so that logical systems can be designed with the proper physical system hardware,
software, forms and/or manual interfaces
• Easily understandable so the people who utilize it on a day-to-day basis can perform their work effectively and efficiently
• Provides evaluation criteria with which to judge its performance
• Identifies the decision points so the proper decision can be made in the work flow progress
System Types :
1. 1. Open and Closed: If it is at all depending on a particular environment, it is an open system and if it functions
independent of the environment, it is a closed system
2. Origin : Natural and Man-made
3. Complexity: Simple and Intricate
4. Outcome: Predictable and Unpredictable
5. Basic Nature: Physical (e.g., Car) and conceptual (Business Organization, School)
Role of a Systems Analyst
• Defining IT requirements of the organization
• Setting priorities among requirements
• Gathering data or facts
• Analyzing and Evaluation
• Problem solving
• Drawing Specifications
• Designing System
• Evaluating System
• Systems Analyst are called: Catalysts, Problem solvers, Detectives, Change
Agents, Architects, Technicians, Imposers, Educators
System Analysis vs. System Design
System Analysis System Design
SA is the examination of the problem SD is the creation of the information system which is
the solution to the problem
It is concerned with identifying all the constraints and It is concerned with the coordination of the activities,
influences job procedures and equipment utilization in order to
achieve system goals
It deals with data collection and a detailed evaluation It deals with general design specification, detailed
of present system design specifications, output, input files and
procedures. It also deals with program construction,
testing and user acceptance
It portrays logical model of the system through Data It provides technical specifications and reports with
Flow Diagrams and Data Dictionaries which the problem can be tackled
System Development Life Cycle
All systems, whether manual or IT based, should be adaptable to change. Systems development is
an ongoing process reflected in the systems development life cycle : Systems Request-System
Selection-Feasibility Study- Acceptance by Management- Data Gathering-Data Analysis- System
Specification- Detailed System Design- Program Writing- Testing & Conversion- System Operation-
Problem Detection- Systems Request
Designing the New System : Systems Analysis is the analysis and selection of the best possible
alternative. System Design is primarily an activity for planning for management i.e., to set
objectives, coordinate activities and monitor performance. The objective of the System Designer is
to make improvements to make the world a better place. It aims to eliminate Inefficiency, Waste,
Ineffective Procedures
Data Gathering : Systems Analyst gathers both facts and opinions pertaining to the problem under
study from every source in the organization interviewing concerned personnel, studying company
reports and memoranda etc. The quality of this data will affect the optimal solution.
Gathering Opinions: Manager’s opinion should be recorded on the overall implication of the system
and at the operating level, the operating staff should be approached for system details.
Other Sources
• Company’s Formal Records: accounting, statistical reports, organization chart, minutes of company meetings
• Existing System Documentation containing written procedures, flowcharts, Programming documentation and
various files
• Publications of Government, computer manufacturers, professional organizations or system professionals
• Opinions from friends, associates in the system field, seminar/convention proceedings and informal
conversation with businessmen
System Requirements Analysis : The Need
Management’s expectation, Analysis of current operations and procedures – Guideline – for the future system
– with a view to find out the deficiencies, malfunctions, inadequacies, expensive, ineffective or unprotected
and uncontrolled operations of the existing system
Evaluate the cost savings and other advantages
The Tools : 6 Kiplings – Why? What? When? How? Where? Who?
Methodology – Facts Gathering, Classify Information, Block Diagram of Procedures, Documenting Information
Obtained, Establishing Organization Chart and Cost Tables, Identify Exception Situations, Establishing Control.
Facts Gathering Techniques, System Investigation
File, Data Analysis & System Specification
• Interviews, Observations, Sampling, Questionnaires, Meetings and Research
• Work Flow Diagrams, Documents Flow Diagram, Information Flow Diagrams Documents
– SA- Kept in a SIF – notes and records
• Summarize the data gathered and displays graphically to facilitate analysis, Prepares
flowcharts of current system, The SA should question every function, documents
produced and procedures followed to device new and better methods and systems
without loosing any of the advantages of the current system. This may lead to improved
ways of doing certain functions and the elimination of unnecessary steps. Study the
system with thoughtful, time consuming analysis to design fairly permanent systems.
Based on Feasibility study + Analysis – System Specification is prepared for the user for
the new proposed system and submitted to the user and management for their
information and approval.
• SA&D is concerned with providing reliability, ease of maintenance, correctness, on-time
delivery, cost effectiveness and efficient use of resources in Information systems.
SDLC
• is about developing a software-driven solution to a business problem
• Concerns a process which takes from 2 months to 2 years
• Really be called a (Business) solution development life cycle
Software Engineering is the establishment and use of sound engineering principles in order to obtain economic
software that is reliable and work efficiently on real machines.
The application of a systematic, disciplined, quantifiable approach to the development, operation and
maintenance of software, that is, the application of engineering to software
A layered technology
tools methods process model a “quality” focus
A Process Framework
Framework Activities Work Tasks Work Products Milestones &
Deliverables
QA Checkpoints Umbrella Activities
Framework Activities
• Communication
• Planning
• Modeling – Analysis of Requirements, Design
• Construction – Code generation, Testing
• Deployment
Umbrella Activities
• Software Project Management
• Formal Technical Reviews
• Software QA
• Software Configuration Management
• Work Product Preparation and Production
• Reusability Management
• Measurement
• Risk Management
The Essence of Practice
• Understand the problem (Communication and Analysis)
• Plan a Solution (Modeling and Software Design)
• Carry out the Plan (Code generation)
• Examine the result for accuracy (Testing and QA)
David Hooker’s General Principles
• The reason it all exists
• KISS (keep it simple, stupid!)
• Maintain the vision
• What you produce, Others will consume
• Be open to the future
• Plan ahead for reuse
• Think!
Business Solution Characteristics
A software - driven solution consists of 2 parts:
• Model – Prototypes, Diagrams and Supporting Documents
• System – Hardware, Software
A Generic Process Model
Software Process – Process Framework, Umbrella activities
The Waterfall model
V-model
The Incremental model
Evolutionary models – Prototyping, The Spiral model, Concurrent
CMM – The CMM for software is used by organization to guide their software process
improvement efforts
1. Initial 2. Repeatable 3. Defined 4. Managed 5. Optimising
Agile Software Development
What is Agility?
• Effective (rapid and adaptive) response to change
• Effective communication among all stakeholders
• Drawing the customer onto the team
• Organizing the team so that it is in control of the work performed
Yielding…..
• Rapid, Incremental delivery of software
An Agile Process
• Is driven by customer descriptions of what is required (scenarios)
• Recognizes that plans are short-lived
• Develops software iteratively with a heavy emphasis on construction activities
• Delivers multiple ‘software increments’
• Adapts as changes occur
The 12 Agile Manifesto Principles
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to a shorter time scale
• Business people and Developers must work together daily throughout the project
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
• Working software is the primary measure of progress
• Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain constant pace
indefinitely
• Continuous attention to technical excellence and good design enhances agility
• Simplicity – the art of maximizing the amount of work not done – is essential
• The best architectures, requirements and designs emerge from self-organizing teams
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
The intent of agile is to align development with business needs, and the
success of agile is apparent.
Agile projects are customer focused and encourage customer guidance
and participation. As a result, Agile has grown to be an overarching
view of software development throughout the software industry and
an industry all by itself.

Key aspects of Agile methodology – Iterative, Incremental, Self-


organizing, Emergent
Human Factors
• The process molds to the needs of the people and team, not the other way
around
• Key traits must exist among the people on an agile team and the team
itself
• Competence
• Common focus
• Collaboration
• Decision making ability
• Fuzzy Problem Solving Ability
• Mutual Trust and Respect
• Self-Organization
User Stories
• Instead of Use Cases, agile project owners do “User Stories”
oWho (user role) – Is this a customer, employee, admin, etc?
oWhat (goal) – What functionality must be achieved/developed?
oWhy (reason) – Why does the user want to accomplish this goal?
As a [user role], I want to [goal], so I can [reason]
Example:
“As a user, I want to login, so I can access subscriber content”.
Story Points: Rating of effort needed to implement this story
Common Scales: 1-10, shirt sizes (XS, S, M, L, XL) etc.
“Pig and Chicken”
Chicken: Hey Pig I was thinking we should open a restaurant.
Pig: I don’t know what would we call it?
Chicken: How about Ham-n-Eggs
Pig: No thanks, I would be committed, but you would only be involved.

Pig: Team member committed to success of project


Chicken; Not a pig; interested but not committed

Plan->Implement->Test->Demonstrate->Inspect & Adapt->Plan


Agile Project Management – Software Development Process Agility of the requirements
Increased communication Continuous Review/Testing
and team ownership Adaptive Teams
Iterative Planning Continuous feedback Deployable Products
Iterative Delivery
Tightly integrated unit
Developers, QA, PM and the customer
Frequent communication Daily meetings – day work and dependencies
Deliveries are short-term 1-week to 4-weeks sprints
Open communication techniques
SCRUM
Scrum is an agile process that allows us to focus on delivering the highest business value in the
shortest time.
It allows us to rapidly and repeatedly inspect actual working software (2-weeks to 1-month)
The business sets the priorities. The teams self-manage to determine the best way to deliver the
highest priority features .
Every 2 weeks to a month anyone can see real working software and decide to release it as is or
continue to enhance for another iteration.
• Originally proposed by Schwaber and Beedle
Scrum – Distinguishing Features
• Development work is partitioned into “packets”
• Testing and Documentation are on-going as the product is constructed
• Work occurs in “sprints” and is derived from a “backlog” of existing requirements
• Meetings are very short and sometimes conducted without chairs
• “Demos” are delivered to customer with the time-box allocated
Scrum Timeline Breakdown
• Agile based projects are broken down into Releases
• At the end of each Release, a working version of the product is delivered to the Business user
• Each Release is made up of a number of sprints
• At the end of each Sprint, a working version of the product is deployed with ‘incremental’ functionalities added over the previous
sprint
• During each sprint, daily scrum calls are held where status update is provided by the team
People + Processes = Product
Applying Scrum to everyday business
o Small prioritized tasks
o Short term commitment
o Daily Review
o Collaboration
o Feedback
o Improvement
• Self-organizing teams
• Product progresses in a series of month-long “sprints”
• Requirements are captured as items in a list of “product backlog”
• No specific engineering practices prescribed
• Uses generative rules to create an agile environment for delivering projects
• One of the “agile processes”
Scrum Framework
• Roles: Product Owner, Scrum Master, Scrum Development Team
• Ceremonies: Sprint planning, Sprint Review, Sprint Retrospective, Daily
Scrum Meeting
• Artifacts: Product backlog, Sprint backlog, Burndown chart
• Product Owner
Product vision
Responsible for ROI
Final arbitrator of requirements questions
Focused more on WHAT than on the HOW
• Scrum Master
Has no management authority
Does not have a Project Manager role
Facilitator
• Scrum Development Team
Cross functional group
Attempts to build a “potentially shippable Product”
Collaborates
Self organizing
Scrum Origins
Jeff Sutherland, Ken Schwaber, Mike Beedle, Mike Cohn
Requirements->Design->Code->Test
Rather than doing all of one thing at a time…..
Scrum teams do a little of everything all the time
Scrum Framework
Roles:
Product Owner, Scrum Master, Team
Ceremonies:
Sprint Planning, Sprint Review, Sprint Retrospective, Daily Scrum Meeting
Artifacts:
Product Backlog, Sprint Backlog, Burndown Charts
Scrum Values Common Values from the Agile Manifesto
1. Individuals and Interactions over Processes n Tools
Scrum is a team based approach to delivering value to the business. Team members work
together to achieve a shared business goal. The Scrum framework promotes effective
interaction between team members so the team delivers value to the business.
Once the team gets a business goal, it:
• Figures out how to do the work
• Does the work
• Identifies what’s getting in its way
• Takes responsibility to resolve all the difficulties within its scope
• Works with other parts of the organisation to resolve concerns outside their control
This focus on team responsibility in Scrum is critical
2. Working software over comprehensive documentation
Scrum requires a working, finished product increment as the primary result of
every sprint. Whatever activities take place during the sprint, the focus is on
the creation of the product increment. A scrum team’s goal is to produce a
product increment every sprint. The increment may not yet include enough
functionality for the business to decide to ship it, but the team’s job is to
ensure the functionality present is of shippable quality.
3. Customer collaboration over Contract negotiation
Scrum is a framework designed to promote and facilitate collaboration. Team
members collaborate with each other to find the best way to build and deliver
the software, or other deliverables, to the business. The team, especially the
product owner, collaborates with stakeholders to inspect and adapt the
product vision so the product will be as valuable as possible.
4. Responding to change over following a plan
Scrum teams make frequent plans. For starters, they plan the current sprint. In
addition, many teams create longer-term plans, such as release plans and
product roadmaps. These plans help the team and the business make decisions.
However, the team’s goal is not to blindly follow the plan; the goal is to create
value and embrace change. In essence, the thought process and ideas necessary
for planning are more important than the plan itself.
A plan created early is based on less information than will be available in the future
so, naturally, it may not be the best plan. As new information is discovered, the
team updates the product backlog. That means the direction of the product likely
shifts. This continuous planning improves the team’s chances of success as it
incorporates new knowledge into the experience.
Scrum teams constantly respond to change so that the best possible outcome can
be achieved. Scrum can be described as a framework of feedback loops, allowing
the team to constantly inspect and adapt so the product delivers maximum value.
Scrum Values
Because we focus on only a few things at a time, we work well together and
produce excellent work. We deliver valuable items sooner.
Courage Because we work as a team, we feel supported and have more resources
at our disposal. This gives us the courage to undertake greater challenges.
Openness As we work together, we express how we are doing, what’s in our way,
and our concerns so they can be addressed.
Commitment Because we have great control over our own destiny, we are more
committed to success.
Respect As we work together, sharing successes and failures, we come to respect
each other and to help each other become worthy of respect.
As an organisation applies Scrum, it discovers its benefits. At the same time, it sees
how these values inherently contribute to the success of Scrum and understands
why they are both needed, and bolstered, by Scrum.
Agile Modeling
• Originally proposed by Scott Ambler
• Suggests a set of Agile modeling principles
• Model with a purpose
• Use multiple models
• Travel Light
• Content is more important than representation
• Know the models and the tools you use to create them
• Adapt locally
Modeling Principles
In software engineering work, 2 classes of models can be created:
• Requirements models (represent the customer requirements by
depicting the software in 3 different domains : the information
domain, the functional domain and the behavioral domain
• Design Models represent characteristics of the software that help
practitioners to construct it effectively : the architecture, the User
Interface and component – level detail
Construction Principles
• The construction activity encompasses a set coding and testing tasks
that lead to operational software that is ready for delivery to the
customer
• Coding principles and concepts are closely aligned programming style,
programming languages and programming methods
• Testing principles and concepts lead to the design of tests that
systematically uncover different classes of errors and to do so with a
minimum amount of time and effort
Validation Principles
After you have completed your first coding pass, be sure you:
• Conduct a code walk through when appropriate
• Perform Unit test and correct errors you have uncovered
• De factor the code
Testing Principles
• All tests should be traceable to customer requirements
• Tests should be planned long before testing begins
• The Pareto principle applies to software testing
• Testing should begin “in the small” and progress towards testing “in the
large”
• Exhaustive testing is not possible
Deployment Principles
• Customer expectations for the software must be managed
• A complete delivery package should be assembled and tested
• A support regime must be established before the software is
delivered
• Appropriate instructional materials must be provided to end-users
• Buggy software should be fixed first, delivered later
Process Assessment and Improvement
• Standard CMMI Assessment method for Process Improvement – provides a
5 step process assessment model that incorporates 5 phases: initiating,
diagnosing, establishing, acting and learning
• CMM-based Appraisal for Internal Process Improvement – provides a
diagnostic technique for assessing the relative maturity of a software
organization; uses the SEI CMM as the basis for the assessment
• ISO 9001:2000 for Software – a generic standard that applies to any
organization that wants to improve the overall quality of the products,
systems, or services that it provides. Therefore, the standard is directly
applicable to software organizations and companies
• ISO 12207
• IEEE standards for SE Processes and Specifications
• SPICE (ISO/IECI15504)
Project Management Practices
As a Project Manager of a system development effort, you are responsible for keeping the
performing organization’s management informed of your project’s progress. There are 3
challenges in this responsibility: reporting meaningful milestones, reporting progress with
the right frequency, and finding a way to highlight the value of your project management
contributions
The Project Management and System Development Cycles
A generic project management life cycle consists of 4 phases, each comprising certain
Project Management deliverables.
Initiation Planning Execution Close Out
Producing the Project Management deliverables is a key aspect of your responsibilities, yet
they obviously should occupy different strata of the corporate awareness.
A generic system development life cycle consists of 4 main phases, each comprising certain
processes, with each process producing certain system development deliverables
Requirements Design Construction Implementation
Aligning the Life Cycles
Initiation ← Requirements
Planning ← Design
Execution ← Construction
← Implementation
Close Out
Identifying the Milestones
Milestones used to report project success in tandem with the corporate reporting cycle
Initiation
Project Charter – first meaningful deliverable – milestone
Business requirements, Functional specifications – Getting a sign-off
Project Manager – identify risks and quality standards, developing a communication plan, defining
main project parameters
Grand Deliverable – Initial Project Plan
Planning, Execution, Close Out
Project Management deliverables defined in Initiation are refined in Planning
First tangible deliverable on the technical side – System Prototype
Technical Specifications Document
Project Plan – include the finalized versions of the Scope, Schedule and Budget – Risk management plan,
Quality management plan, Project implementation and transition plan, Organization change management plan
Execution
Integration Test – Acceptance
User manuals Training materials
System Deployment
Data validation
System transition – Execution formally ends
Close Out
Lessons Learned
Project Assessment Report
Project Management Template
PM Phase PM Processes Project Milestones SD Processes SD Phase
Initiation Define Project Project Charter Identify Business Requirements
Parameter, Identify Subsystem 1 Requirements
risks and quality Business Define Process and
standards, Develop requirements Data Models
initial Project Plan Subsystem n Produce functional
Business specifications
requirements
Subsystem 1
Functional
Specifications
Subsystem n
Functional
Specifications
Initial Project Plan
Planning Refine Project System Prototype Define Technical Design
Parameters Subsystem1 architecture
Evaluating Systems-Efficiency and
Effectiveness Metrics
The performance of the system can be measured by 2 factors viz.,
1. The Efficiency (Do Things Right) Measure the performance of MIS itself including throughput,
speed and availability
2. The Effectiveness (Do the Right Things) Measure the impact MIS has on business processes and
activities including customer satisfaction, conversion rates and sell-through increases
Doing things right addresses efficiency-getting the most from each resource. Doing the right things
addresses effectiveness – setting the right goals and objectives and ensuring they are
accomplished.
Effectiveness focuses on how well an organization is achieving its goals and objectives, while
efficiency focuses on the extent to which an organization is using its resources in an optimal
way. The two – efficiency and effectiveness – are definitely interrelated. However, success in
one area does not necessarily imply success in the other.
Efficiency Metrics – Throughput, Transaction speed, System availability, Information accuracy, Web
traffic, Response time
Effectiveness Metrics – Usability, Customer satisfaction, Conversion rates, Financial

Вам также может понравиться